Re: Best practice to corrupt data

nospam_at_gojko.com wrote:
> A common practice for handling errors in PL/SQL procedures is to catch
> all errors in the top-most database layer and convert them into error
> codes and human readable messages for client applications. This
> technique is a relict from the past and, in fact, a very bad practice
> from today's perspective, since it can lead to data corruption. More on
> http://www.orafaq.com/node/993 .
>
> Gojko Adzic
> http://www.gojko.com

Blog by Gojko recommends handling database exceptions in calling programs rather than in stored code in the database.

My take: exceptions should be handled as close to where the exception occurs in the stored code as possible and then re-raised and handled again in the calling program. By capturing the exception in the database all variable information in the code can be logged via an anonymous transaction and thus made available to developers for debugging. Trying to get a customer to relay the information off of an error screen is unrealistic. In fact my experience errors are often not reported or the report is delayed. By then the error information returned or captured by the application is no longer available.

Argument against passing Error codes as parameters has merit. I have never really liked doing that as a blanket rule. There are applications where it is a good idea and times when it is just better to kill the program and return control to the caller but again only after capturing execution data.

IMHO -- Mark D Powell -- Received on Tue Sep 26 2006 - 12:58:33 CDT