Exception Handling

Every good software developer will not only focus about the bright side in IT world but will always consider the stuff which can go wrong.

The general concept of doing this across nearly all programming languages in the world is the concept of "Exception Handling" and nearly every software developer out there should be familiar with this.

In the ABAP world we have two approaches to handle those exceptions: static exceptions or exception classes.

Static exceptions

An older approach via static exceptions which will fill system variable SY-SUBRC, if something went wrong.

Advantages

  • Easy to create them (one line of code).

  • Easy to raise them.

 RAISE EXCEPTION <myExeption>

or

 MESSAGE ... RAISING <myException>

Disadvantages

  • No OO approach.

  • No automatic Exception Propagation along the callstack.

  • No reusability.

  • No Exception chaining.

  • No additional data about the problem since only sy-subrc is filled (maybe also the message variables are filled sy-msgno sy-msgid sy-msgv1-4, sy-msgty but this depends on the developer raising the Exception if he did this with: MESSAGE …​ RAISING <myException>).

Exception classes

  • A modern approach via exception classes.

Advantages

  • Reusability

  • Automatic Exception Propagation.

  • Exception Chaining (PREVIOUS attribute of the exception class).

  • Since it is an instance of an exception ABAP Class you can define additional attributes which can contain additional information about the cause of the problem.

  • Modern OO approach.

Disadvantages

  • More effort to define them (create a new class, etc …​).

  • A minimal effort to raise them (but makes sense since you also will have more information later on).

Example Exception call of /NEPTUNE/CL_DR_LIB_SRC_PROG_X
RAISE EXCEPTION TYPE /neptune/cx_dr_prog
                EXPORTING textid   = /neptune/cx_dr_prog=>variant_does_not_exist
                          progname = me->progname
                          variant  = variant.

Representation of Exceptions in the HTTP World

Since an exception semantically means that "something went wrong" the API Factory will represent their occurrence as an HTTP 500 Status Code.

But how to get now additional information about the root cause of the exception?

We will fetch ALL Information about the exception accessible from ABAP (old exceptions and new class based exceptions) and return their information as a JSON Structure in the Response Body.

So you can handle the error in the most detailed way possible.

Ok that’s cool. What about Open API and Swagger UI? Can I see which exceptions might occur?

The answer is yes!

The signature of the method which represents the executable endpoint will be analyzed by the metadata class and all Exceptions defined there will be represented in Swagger UI.

Related topics