In the series of the Class-Based exception raising & handling exceptions, today we’ll see design time considerations.

Checkout all post related to Exception Raising & handling:

• Function Module Exception Handling
• Raising & Handling Non-class based exceptions – I
• Raising & Handling Non-class based exceptions – II
• Class-based Exceptions I – Basics
• Class-based Exceptions II – Design Time consideration
• Class based Exceptions III – Runtime flow
• Class based Exceptions IV – CLEANUP
• Exception class to use Messages from T100
• Why NOT to have a wrapper around Exception (RAISE) ?

Main classes

All Exception classes are inherited from the global exception class’s CX_ROOT these subclasses:

• CX_STATIC_CHECK – If the exception is defined as a subclass of CX_STATIC_CHECK, it has to be declared in the method or FM signature. If the exception is propogated from the method or FM, it has to be explicitly declared in all the FM or method signature. If the exception is not declared, it has to be caught. If not caught neither declared, it would result into run-time error.
• CX_DYNAMIC_CHECK – If the exceptions are inherited from CX_DYNAMIC_CHECK, they also needs to be declared in the FM signature. If not, they wont be checked at design time. Generally, all system exceptions like CX_SY_ZERO_DIVIDE begins with CX_SY. All of them are inherited from CX_DYNAMIC_CHECK.
• CX_NO_CHECK – Exceptions that are defined using subclasses of CX_NO_CHECK must not be declared explicitly in the interface of the procedure. The class CX_NO_CHECK and its subclasses are implicitly always declared and are always propagated.

Since it compiler helps us to identify if we have missed declaring or catching the exception, we should create our exceptions as a subclass of CX_STATIC_CHECK.

Compile Time Flow

In words..

• If the exception is inherited from CX_STATIC_CHECK, it has to be declared in the FM / method signature or it has to be caught. Compiler will give an warning check whenever this propagation sequence is terminated.
• If the exception is inherited from CX_DYNAMIC_CHECK, compiler will not produce any warning.
• If the exception is inherited from CX_NO_CHECK, it must not be declared in the signature. If it is declared, syntax error will occur.

Further Reading

Checkout all post related to Exception Raising & handling:

• Function Module Exception Handling
• Raising & Handling Non-class based exceptions – I
• Raising & Handling Non-class based exceptions – II
• Class-based Exceptions I – Basics
• Class-based Exceptions II – Design Time consideration
• Class based Exceptions III – Runtime flow
• Class based Exceptions IV – CLEANUP
• Exception class to use Messages from T100
• Why NOT to have a wrapper around Exception (RAISE) ?