ABAP, like any programming language, has its pros and cons. One of the disadvantages is that there are many topics that are implicit rather than explicit.
Implicit means to me that you have to know a certain fact because neither the development environment nor the runtime environment provides any hint about it.
An example: whether a READ TABLE statement was successful or not is determined via SY-SUBRC. This is an implicitly available variable that initially has no direct connection to the READ TABLE statement. Consequently, you have to know this special relationship.
SY-SUBRC can also take on different numerical values to indicate different situations. Almost like a secret language for insiders. You learn this from other developers or from the ABAP Keyword Documentation, which has now become really extensive.
Sometimes SY-SUBRC is not even related to a preceding statement. At least in the majority of cases. Exceptions prove the rule. Table expressions are a good example here. If a row is not found, the exception CX_SY_ITAB_LINE_NOT_FOUND is triggered.
Without appropriate handling, this results in an unhandled exception at runtime, causing a runtime error. This is somewhat more explicit, but still not ideal. If you only test the success scenario in your unit tests, you might encounter a runtime error based on CX_SY_ITAB_LINE_NOT_FOUND for the first time in production. That’s frustrating.
Why am I writing this here? I don’t like many of the implicit behaviors in ABAP. They force me to frequently look things up in the documentation or to keep many details in my head, most of which I rarely need.
The latest case in this context: the classic, i.e., non-class-based standard exception ERROR_MESSAGE in function modules. It controls the behavior when the MESSAGE statement is used within the logic of the function module.
Where to read more about this? Of course, in the ABAP Keyword Documentation.