Figure 6-1. Exception-handling architecture
Adopting an Exception-Handling Strategy
PL/SQL exception handling is very powerful and flexible, but it can also be confusing and tricky. It is extremely important to establish a consistent strategy and architecture for error handling in your application before you write any code. To do that, you must answer questions like these:
· How and when do I log errors so that they can be reviewed and corrected?
· How and when do I report the occurrence of errors back to the user?
Linked tightly to these very high-level questions are more concrete issues, such as:
· Should I include an exception-handling section in every one of my PL/SQL blocks?
· Should I have an exception-handling section only in the top-level or outermost blocks?
· How should I manage my transactions when errors occur?
Part of the complexity of exception handling is that there is no single right answer to any of these questions. It depends at least in part on the application architecture and the way it is used (batch process versus user-driven transactions, for example). However you answer these questions for your application, I strongly suggest that you "codify" the strategy and rules for error handling within a standardized package. I address this topic at the end of the chapter.
The rest of this chapter introduces the concepts behind PL/SQL exception handling, explains the different types of exceptions, and shows how to both raise and handle errors in your code.