-
Notifications
You must be signed in to change notification settings - Fork 0
Add Exception Mapper
Exception mappers are used to extract the relevant data from an exception while logging it. They are based on the interface /USI/IF_BAL_EXCEPTION_MAPPER, that offers two methods.
Chances are you will never need your own exception mapper.
You would only need one, if you had an exception class, that contained additional data (such as e.g. an internal table), that is NOT encapsulated in a data container. Before writing a custom mapper for that, I would rather recommend, to encapsulate the additional data in a data container and to use the standard mapper, as this is more straigthforward.
All implementations should delegate the call to the text getter of the Exception API.
If the text getter should not work, as expected a new plugin class for the text getter might be needed. Please refer to the documentation to find out, how to create it.
The interface method exists "for historic reasons", as the text extraction was originally "invented" for the logging API before it was moved to the exception API. As the interface had already been rolled out and custom implementations of that interface might exist, deleting the method declaration was no longer feasible.
Extracts additional data from the exception (if found) and returns them as a data container collection (TYPE REF TO /USI/IF_BAL_DATA_CONTAINER_COL).
The API is shipped with the default mapper /USI/CL_BAL_EM_BASE, that will already recognize all public instance attributes of an exception having the following types:
- TYPE REF TO /USI/IF_BAL_DATA_CONTAINER (Single data container)
- TYPE REF TO /USI/IF_BAL_DATA_CONTAINER_COL (Data container collection)
If you should ever need a custom exception mapper, I would recommend to copy the class /USI/CL_BAL_EM_BASE. After that, just enhance the method /USI/IF_BAL_EXCEPTION_MAPPER~GET_DATA_CONTAINERS as needed.
Once created a new mapper has to be maintained in the customizing (see: Customizing -> Exception Mappers).