In a previous ABAP Objects: Custom SAP ERP HCM Class Library – Example 3 – Exceptions, I described a general exception handling class ZCX_MESSAGES. The aim of the class is to help developers unify their exception handling. It is based on the brilliant IF_RECA_MESSAGE_LIST interface, which I found by reading Uwe Schieferstein’s Wiki Message Handling – Finding the Needle in the Haystack. Using the ZCX_MESSAGES exception class has turned out to be a success and well adopted by my peer developers at various SAP customers. It is robust, easy to understand, easy to use, backwards compatible, object-oriented and does solve the vast majority of ABAP exception handling needs. Having said that, I still think it is possible to write better exception handling, but that will imply more development efforts.
Whereas my previous blog presented a tool for exception handling, this blog focuses on how to use exceptions in general. There are numerous types of exceptions. In the following, I will shed some light on a few exception handling examples and how they affect the process flow; Retry, Add, Pass On, and Suppress.
Lets have a look at the scenario before going into more details with the types of exception.
The image depicts an ABAP process flow, i.e. the order in which the code is executed. In the examples below, a level is represented as a class. The boxes are either a method or a processing block within a method. As you will see, the exception handling does have a severe impact on the ABAP process flow.
The idea of the Retry exception type is basically to use the exception handling to catch an exception, process the error, and fix the issue. Fixing the issue can be done in a multitude of ways. Below I show a simple example where the method that threw the exception is recalled with another importing parameter.
Lets assume that an exception is thrown in C11. In B1 the exception is caught and C11 is recalled. Besides recalling C11, there is no disruption in the overall ABAP process flow.
Since release 7.0 EhP2 there is a type of exception called resumable. The ABAP Keyword Documentation describes resumable as “When a resumable exception is handled in a catch block, you can resume processing with the statement RESUME directly after the triggering statement if the context of the exception still exists”. I recommend debugging program DEMO_CATCH_EXCEPTION for better understanding of the resumable exception type.
Resumable is similar to retry, but there are some significant differences. An advantage is that the context is kept and therefore the processing before the exception does not have to be executed again. In my opinion a drawback is that RESUMABLE has a syntax of its own. For example, instead of CATCH you need to write CATCH BEFORE UNWIND. It is not possible to have a regular CATCH and CATCH BEFORE UNWIND for the same TRY block, which I find makes the exception handling less flexible. When raising an exception you need to add RESUMABLE, i.e. RAISE RESUMABLE EXCEPTION.
Remember to check the Resumable checkbox when declaring method exceptions, as shown in the screenshot below.
An exception is thrown in C11. In B1 the exception is caught and the processing is resumed in C11 where the exception was raised. Besides the exception handling, there is no disruption in the overall ABAP process flow.
The Add exception type focuses on catching the exception and adding a message to message list before rethrowing the exception. One reason for doing this could be to keep track of the message path, i.e. a custom call stack.
Lets assume that an exception is thrown in C12. The exception is caught in C11. In C11 a message is added to the message list and the exception is rethrown. The exception is caught in B1, another message is added and the exception is rethrown. Finally, the exception is caught in A. In A the developer needs to decide how to handle such exceptions. If nothing is done to repair the issue, then the ABAP process flow stops at C12.
Unfortunately, too many ABAP Objects developers will recognize this type of exception handling. The Suppress exception type simply catches an exception and does nothing about it. As with all problems that are suppressed, they will eventually come back and haunt you when you least expect it. This is not good practice.
Lets again assume that an exception is thrown in C11. The exception is caught in B1. The problem is suppressed and B1 calls B2 as if nothing has happend. The rest of the ABAP process flow continues, however, there is a big risk that something is missing due to the fact that C11, C12, C13, and C14 were never properly executed.
Finally, there is the Pass On exception handling. This exception handling resembles the Add exception type. Unlike Add, Pass On simply passes the exception on to the next calling layer. As with Add, it is usable whenever the process flow should actually be stopped.
An exception is thrown in C11. In B1 the exception is simply passed on to A. The ABAP process flow stops.
Please read the ABAP Keyword documentation for much more information on exception handling.