Try OpenEdge Now
skip to main content
Error Handling
Raising errors with THROW : Propagating errors up the stack
 

Propagating errors up the stack

The best practice for most error handling is to handle the error locally. For both traditional and structured error handling, ABL default behavior supports handling the error as close to where the error occurred as possible. ABL attempts to minimize the amount of work that has to be undone, and it provides branching options to help resume execution.
In practice, localized error handling means that each block should have enough CATCH blocks to handle any error that can be reasonably expected to occur within the block. This makes code more readable and maintenance straightforward.
However, there are also numerous use cases where handling errors in a central location makes more sense. For example, suppose you have a code module with many blocks that can fail with the same type of error. If there is no advantage to a local CATCH block, and your error handling code is the same for all blocks in the module, then THROW all the errors up the call stack to a central location where a single CATCH can handle them all.
In many cases, you can provide local CATCH blocks that require specific error-handling behavior to support your business logic. But even if your application handles all predictable errors, this still leaves unexpected system errors as a potential problem. You can use THROW directives to move unhandled system errors from the block in which they occur to outer blocks, until they reach some central point where you have a common CATCH block set to handle them—perhaps, for example, by providing common logging and graceful exit behavior.
The technique of directing a containing context to handle errors raised in an inner context is often described as propagating errors up the call stack. The remaining sections in this chapter examine the use of THROW to apply this technique in your application code.