Example: SY-SUBRC based exceptions
Introduction
Let’s create the Sales order Example from the previous example with the old approach instead of class based exceptions. * Example: Class based exceptions with exception chaining
Example
First we create the exceptions in a new interface method called ZIF_DR_SALESORD_RUNTIME_PATCH~SALESORDER_OLD_EXCEPTIONS.
Since we don’t can make use of exception chaining we can decide whether we want to have only one abstract exception meaning that the Salesorder couldn’t be changed or if we want to also have dedicated exceptions for the various problems which could have happened.
In our example we define the exceptions like this:
And implement the method as follows:
You should notice some things which are not really elegant:
-
If you have detailed inner exceptions and want to transport their semantics to the "outside" you have to define them again. ⇒ No re-usability possible.
-
No additional data can be passed along those inner exceptions (except sy-msgv variables), so you might lose important information about the root of the actual problem.
This should already highlight that you should try to use class based exceptions as often as you can.
Let’s take a look at the SY-SUBRC based exception representation in Swagger UI (Open API Version 3.0):
In the "Examples" Dropdown List you will see all possible exceptions which might occur and how their response body Payload will look like (Open API 3.0).
When we execute it and the actual error happens we will get the following HTTP 500 Response:
The raw response body payload will look like this"
{
"DESCRIPT": "Salesorder currently locked by a user.",
"EXCEPTION_ID": "SALESORD_LOCKED_BY_ANOTHER_USR",
"MSG": {
"MSGTY": "E",
"MSGID": "ZSD_SALESORDER",
"MSGNO": 2,
"MSGV1": "5021"
},
"SUBRC": 2,
"SYSTEM": "NAD",
"TEXT": "Salesorder 5021 is currently locked by someone"
}
So again you will get all information which is available and can handle the exception as good as possible.
Keep in mind that you only get the MSG and TEXT properties because the exception has been raised with the ABAP Statement MESSAGE …. RAISING …. .
If the exception had simply been called with statement RAISE …. you would get less information.
This would look like this:
Also, you have to keep in mind that the API Factory simply reflects the current sy-msg variables during the occurence of the exception. These might have been filled before with a message related to another semantic. Thus the Message might not be related to the exception.
How could this look like in ABAP?
When you don’t want to catch it you get of course a DUMP which can be reviewed with ST22.
If you caught it and want to handle it this could look something like this:
It should be very obvious that the handling of sy-subrc based exceptions has many disadvantages and the exception handling is a lot better when you are using class based exceptions.
Summary
Since we embed as much information as possible into the HTTP 500 Response body a client who consumes an API build with the API Factory should be able to handle exception scenarios as good as the ABAP Developer can do this with the concepts inside the ABAP world. Both with class based and SY-SUBRC based exceptions.
Reuse your business logic and SAPs concepts