모든 exception class는 아래 3가지 class들 중 하나의 subclass가 되어야 한다. 이 3개의 class들은 CX_ROOT로부터 파생된 것이지만, 내가 직접 CX_ROOT로부터 파생된 class를 만들어 사용할 수는 없다.
언제 어떤 것을 사용하느냐 – 를 생각해보자. 약간씩 틀리긴 하다.
Subclasses of CX_STATIC_CHECK
The relevant exception must either be handled, or propagated explicitly using the RAISING addition. If this is not the case, the syntax check displays a warning.
If you define your own exception classes, CX_STATIC_CHECK is defined as the superclass by default.
Subclasses of CX_DYNAMIC_CHECK
You must either handle them or explicitly propagate them using the RAISING addition. The difference is that this is not statically checked. No syntax warning is reported if the exception is neither handled nor propagated. If the exception is then raised, a runtime error occurs.
Typical examples of this situation are the predefined exceptions CX_SY_… for errors that occur in the runtime environment. These are usually subclasses of CX_DYNAMIC_CHECK.
Subclasses of CX_NO_CHECK
The corresponding exceptions cannot be propagated explicitly using the RAISING addition. These exceptions can be handled. Otherwise they are automatically propagated. Neither a syntax warning nor a runtime error is caused directly where it is raised. Instead all exceptions that are not handled somewhere in the call hierarchy are propagated up to the highest call level. If it is not caught there either, a runtime error occurs at that point.
Some predefined exceptions with the prefix CX_SY_… for error situations in the runtime environment are subclasses of CX_NO_CHECK.