Should Every Stored Procedure Have an Exception Block?

Question

I have a client who runs an Oracle 11 database. The DBA for this client insists that every stored procedure added to the database contain an exception handler (even if the sproc just does a SELECT). Does this make any sense? Our data layer on the web site already has built-in exception handling and logging (which works well). The data layer is written in .NET.

I have told the DBA that an exception handler is only called for when there is some specific action that can be taken in case of an error (like a transaction rollback), or when some predictable error is likely to occur.

He insists that every sproc have an exception block.

Any opinions on whether this is a good or needed practice would be appreciated.

Thanks!

Answer 1

I can't speak to any Oracle-specific need that this may be satisfying. Maybe there's something the DBA knows that we don't?

But, in general, you're correct. An exception handler is needed only where one can meaningfully handle an exception. If there's nothing that can be logically done at that point in the code, then there's no reason to catch an exception. (I wonder... would the DBA's requirement be satisfied if the exception handling block did nothing but re-throw?)

Now, having said that, there's also a certain amount of prudence is following the coding standards set forth by the team which owns a particular system. That is... Is this a fight worth having? (In my own personal and not universally applicable experience, this is a particularly grueling fight with DBAs. Especially DBAs in charge of dinosaurs like Oracle or DB2. But take that with a grain of salt.)

A good compromise in a situation like this would likely be to sit down with the DBA and discuss what he/she expects the exception handler to do . Logically determine, collaboratively, how to meaningfully handle exceptions in this particular stored procedure. The DBA may see that there's less need for it, or conversely you may find a need for it that you hadn't considered. Either way, it's a good opportunity to arrive at an understanding of an otherwise coarsely-expressed blanket rule as it applies to a specific scenario.

Answer 2

This is a similar argument as when to use a checked exception vs. an unchecked exception in Java. It can be a matter of opinion, but it seems to me that a good starting point is what you have already said: catch the exception if there's a way you can deal with it.