7

I'm relatively new to ABAP development and have more experience in Java and similar languages. In Java, any exception that is thrown and not caught is automatically propagated up the call chain so that you can decide how to handle it at the highest (user-facing) level of your program.

I would now like to do the same thing in some of my ABAP reports where I use class methods or function calls, some of which go several levels deep. Especially for reports meant to run in a job, I want to make sure that all exceptions are handled. This works fine as long as you specify each possible exception in the raising or exception block of a method. I realise however that I regularly use functions or methods that will raise a certain exception that I don't explicitly mention in the definition of the method calling them. I was under the assumption that these would simply propagate up but a section of the ABAP documentation seems to indicate that this is not the case.

My question now is if it makes sense to use a TRY [...] CATCH cx_root block in my report. While this correctly catches any exceptions thrown in the block that don't have a specific CATCH statement, the documentation seems to suggest that exceptions not specifically mentioned in a method definition will throw a short dump for an unhandled exception rather than moving up the call chain to see if the exception is handled there. Can anyone confirm this?

Boghyon Hoffmann
  • 17,103
  • 12
  • 72
  • 170
Lilienthal
  • 4,327
  • 13
  • 52
  • 88

1 Answers1

9

It depends - in this case on the exception class hierarchy. You cannot subclass CX_ROOT directly, you have to use one of its direct subclasses:

  • subclasses of CX_STATIC_CHECK have to be handled or propagated, otherwise the program is syntactically incorrect
  • subclasses of CX_DYNAMIC_CHECK do not require handling or propagation, but will abort the program that does not handle or propagate the exception
  • subclasses of CX_NO_CHECK will always be propagated automatically unless handled

Catching CX_ROOT inside the application is usually a bad idea, unless you really know what you're doing. Don't try to catch stuff you can't handle.

vwegert
  • 18,371
  • 3
  • 37
  • 55
  • 1
    And to add to that, some exceptions are not catachable by design. – Raven Dreamer Jan 22 '14 at 19:57
  • 1
    As I did in Java so do I in ABAP. Every new exception class that I introduce is always a subclass of `CX_NO_CHECK` which more or less corresponds to the class of `RuntimeException` in Java. The `CX_STATIC_CHECK`is like the handled exceptions in Java (subclasses of `Exception`). `CX_DYNAMIC_CHECK` is a special invention of the ABAP Objects designers. :-) – Jagger Jan 23 '14 at 07:03
  • So while the documentation states that you can't add a `RAISING` statement for `CX_ROOT` or `CX_NO_CHECK`, you don't actually have to anyway for the latter since it always propagates? Can I then replace the catch on `CX_ROOT` with one on `CX_NO_CHECK` to accomplish what I want, which is to catch any and all unhandled but non-critical exceptions thrown by FMs and methods I may be calling in my code? – Lilienthal Jan 23 '14 at 13:28
  • Also, catching CX_ROOT might prevend an abend, which means you will not have ST22 to figure out what went wrong, that is not a good place to be. – tomdemuyt Jan 29 '14 at 17:14
  • @tomdemuyt: Even worse, it might prevent the error from being noticed at all. Three years later, someone might accidentally discover that your program has been corrupting sensitive data ever since - very amusing. Not. – vwegert Jan 30 '14 at 10:07