Exceptions vs. SY-SUBRC

Programmierung des Happy Path

Teilweise sind bei Rückgabewerten (SY-SUBRC) 50% des Codes mit Fehlerhandling beschäftigt. Mit Exceptions liegt der Fokus auf dem Happy Path, die Fehlerverarbeitung kann man das zentral erledigen.

Exceptions können Logik enthalten

Welche Daten für eine Meldung notwendig sind oder ob sich eine Exception selber in einem Log speichern kann, dass kann ich in der Exception (bzw. einer Superklasse) implementieren.

Fehlerverarbeitung kann zum Aufrufer delegiert werden

Oft spielt der konkrete Grund im Code keine Rolle. Ob das Speichern scheitert, weil die Berechtigung nicht ausreicht, eine Sperre sitzt oder eine Validierung scheitert, das ist oft im Code egal. die Reaktion ist immer gleich: Abbrechen und Meldung ausgeben. Das kann oft eine übergeordnete Methode erledigen.

Exceptions können nicht ignoriert werden

if sy-subrc <> 0.
  "ToDo - Fehlerverarbeitung mach ich später...
endif. 

CX_STATIC_CHECK

Vorteile

• Der Aufrufer wird informiert, dass er sich um die Exception kümmern muss. In der IDE eine Warnung, beim ATC-Check oft ein dunkelroter Fehler

Nachteile
Jede Ebene muss die Exception entweder behandeln oder propagieren:

• Viele Deklarationen
• Unflexibel bei Änderungen
• Der Aufrufer muss wissen, wie er angemessen reagiert
• Falls die Exception nicht deklariert wird, kommt es mit der weniger aussagekräftige Exception CX_SY_NO_HANDLER zum Dump

Wann verwenden

• Für Schnittstellen, die auch von anderen Entwicklern/Teams verwendet werden
• Wo der Aufrufer auf die möglichen Fehler hingewiesen werden soll

I think CX_STATIC_CHECK adds too much noise everywhere it's used. CX_STATIC_CHECK is just like using checked exceptions in Java, it forces people to add empty catch blocks, deal with exceptions that they have no idea how to deal with, or to propagate exceptions in their method signatures needlessly. (https://github.com/SAP/styleguides/issues/138)

Beispie ZCX_NO_CHECK

Erzeugung einer Exception mit Message

Früher war es üblich, eine Konstante vom Typ T100KEY für jede mögliche Exception vorzusehen.

Mit 7.50? ist es möglich, einfach beim RAISE EXCEPTION TYPE die Message mitzugeben. Das ist für alle Exceptions möglich:

      RAISE EXCEPTION TYPE zcx_nc_validation
              MESSAGE e001(zbc_msg)
                 WITH lv_fieldname
                      lv_value.

"Oder in Langform: 
      RAISE EXCEPTION TYPE zcx_nc_validation
             MESSAGE ID 'ZBC_MSG'
                     NUMBER 001
                     WITH 'Name'
                          'Grummelmumpf'.

Vorteile

• Einfach und flexibel
• Verwendungsnachweis der Messages funktioniert
• Die Nachrichten müssen nicht vorher in der Exception-Klasse als Konstante hinterlegt werden
• Es können beliebige Nachrichten erzeugt werden

PREVIOUS

Falls eine Exception auf einer anderen Exception basiert, so sollte diese im optionalen Parameter ´PREVIOUS´ mit angegeben werden:

TRY.
    calculate( ).

  CATCH cx_sy_zerodivide INTO DATA(lx_prev).
    RAISE EXCEPTION NEW zcx_validation( previous = lx_prev ).
ENDTRY.

Vorteil

• Es lässt sich nachvollziehen, was der ursprüngliche Fehler war
• Die Position im Quellcode lässt sich von ´PREVIOUS´ abfragen, um die passende Codestelle zu finden

Soll ich CX_ROOT abfangen?

Damit fängt man 90% aller Dumps ab. Aber nein - das ist normalerweise keine gute Idee.

Was mir mal passiert ist: Der Kunde hatte ein großartiges Framework im BW gebaut. Aber eines Tages hatte ein einzelner Prozesse am Ende einfach nichts (In Zahlen 0) mehr gemacht. Keine Änderungen an den Daten, kein Dump. Einfach nichts. Von heute auf morgen hatte der Prozess einfach nicht mehr funktioniert.

Der Grund: Es wurde CX_ROOT abgefangen. Damit ist eine Exception vom Typ CX_NO_CHECK bei einem Datenbankfehler abgefangen worden. Leider hat man versäumt, die Fehlermeldung auch auszugeben.