Since Neptune DXP 6 we were catching all exceptions (cx_root) that occured in the method call of the API Class.

This is not ideal due to the following reasons: 1. Exceptions in general are not a bad thing: When something really goes wrong you might want to get a proper ST22 dump and see where the problem occured. With the catching of "everything" you won’t get a ST22 dump. 2. The creator of the API might want to control if information of the dump should be send to the frontend or not. To adress these issues we now only catch cx_dynamic_check and cx_static_check and not cx_root. You can learn more about these exception categories here: https://blogs.sap.com/2021/10/26/declaration-of-cx_no_check-exception-in-raising-clause/

With that you get a ST22 dump for unhandled exceptions (cx_no_check) but if you declared the exception in the method call you get very detailed information about it in the response body payload so you are able to handle the problem very precicely in the frontend. In addition to that we also reflect the exceptions you declared in the method signature in our Open API specification (you can see that in Swagger UI) to highlight what are the declared exceptions in the method and to show the possible response payloads for them. Here an example from our Unit Test API on the GET /intentionalError Operation:

When executing the GET /intentionalError endpoint you receive the following response payload and an HTTP 500 status code. Also no dump would occur in ST22:

If you would don’t have the cx_sy_zerodivide exception in the method signature of /NEPTUNE/CL_UNIT_TEST_API→GET_INTENTIONAL_ERROR you would end up with a "real" exception tha also shows up in ST22:

So you have full flexibility on how you want to deal with exceptions and even can use them to do enhanced handling in the frontend because the response body of the exception will give all the details about the abap exception class including possible exception chaning (previous).