Wozu Exception Objects

[Matti Mäkitalo]

Hallo,

du musst dir überlegen, was die Alternative zu exceptions sind. Eine Exception transportiert im Wesentlichen 2 Dinge: der Grund oder wenigstens die Kategorie des Fehlers (i.d.R. durch die Klasse ausgedrückt) und eine Payload, die die Begleitumstände beschreiben kann.

Wichtig: die Payload kann für jeden Fehler unterschiedlich sein. Nehmen wir mal eine Funktion, die einen HTTP-Call irgendwohin macht. Mögliche Exceptions wären sowas wie HostNotFoundException (Domain nicht auflösbar), NetworkException (es kommt keine Netzwerk-Verbindung zustande), AuthorizationException (konnte nicht authorisieren), diverse HTTPError (z.B. HTTP-Request liefert Status 400, 500, 404) und zu guter letzt noch Parsing-Fehler beim Inhalt (d.h. der Body entspricht nicht dem, was der Client erwartet, z.B. kein gültiges JSON).

Die "normale" Implementierung ohne Exception macht das über Rückgabewerte. D.h. zusätzliche zum eigentlichen Rückgabewert gibt die Funktion noch einen Statuscode zurück. In golang z.B. i.d.R. erster Returnwert Status, zweiter Returnwert dann der eigentliche Wert der Funktion (in unserem Beispiel also die Response des HTTP-Calls).

Da wir noch eine Payload haben wollen (z.B. der HTTP-Body, damit wir ihn später loggen können), brauchen wir schon drei Rückgabewerte: Status-Code, Payload, eigentlicher Funktionsreturn.

Dann stossen wir schnell auf das Problem, dass für verschiedene Status die Payload unterschiedlich ist. Wenn man eine Sprache mit Superklasse oder ähnliches (stdclass, Object, void*) nutzt, muss man das dann nutzen. In anderen müssen die Payloads schon von einer gemeinsamen Basisklasse erben um ein wenig Typsicherheit zu erreichen.

Wenn ich dann eine solche Funktion aufrufe, sieht das dann so aus:

int statusCode; Object exceptionPayload; MyType returnValue;
(statusCode, exceptionPayload, returnValue) = myFunction(param1, param2);

if (statusCode == FEHLER_CODE_1) {
   doSomethingWithPayload(exceptionPayload);
} else if (statusCode == FEHLER_CODE_2) {
   doSomethingElseWithPayload(exceptionPayload);
} else {
   // hey, happy path!
   doSomethingWithReturnValue(returnValue);
}

und das für jeden einzelnen Funktionsaufruf. Und hier habe ich schon eine golang-ähnliche Syntax verwendet. Andere Sprachen, die nicht mehrere Returnwerte kennen, müssen dann entweder Referenzen als Outputparameter nutzen oder eigene Returntypen schreiben.

Exceptions machen das zunächst mal einfacher.

1. Exceptions bündeln Status Code und Exception Payload.
2. Exceptions bubbeln den Call-Stack automatisch nach oben, wenn sie nicht gefangen werden. (Bei Funktionsaufrufen musst du jeden einzelnen Funktionscall separat prüfen).
3. m.E. ist der Happy-Path (der Code-Pfad, in dem nichts schief läuft) einfacher zu lesen. Fairerweise sei erwähnt: der Code-Pfad, in dem etwas schiefläuft, wird dadurch schwieriger zu lesen, insb. wenn man bubbeln lässt; dieser lässt sich dann nicht mehr linear lesen.

Viele Grüße Matti