Hallo,

Exceptions haben bekannterweise vier Konstruktoren - den Standardkonstruktor, einen Konstruktor mit der Nachricht, einen Konstruktor mit der Ursache und einen mit beiden als Parameter.

Gibt es eine beste Praxis für die Nutzung der Konstruktoren, eigentlich der letzten drei, so dass die Verschachtelung der Exceptions nicht zu einem unauflösbaren Knäul führt, der 'catch'-Bereich möglichst einfach bleibt und der Stacktrace gut leserlich wird (wahrscheinlich kann man an dem Stacktrace nicht so viel ändern) (insbesondere bei mehrmals ineinander geschachtelten Exceptions) ?

Meine zweite Frage: Wie sinnvoll ist der Entwurf einer eigenen Exceptionshierarchie (bei Mehrschichtenarchitekturen oder bei Applikationen mit vielen Komponenten), um die oben aufgeführten Ziele zu erreichen?


Falk

Nested Exceptions sind oft ein Code Smell - also ein Zeichen für zweifelhaftes Design.

Sollten eher selten vorkommen. http://stackoverflow.com/questions/29554...other-exception

Eigene 'sprechende' Exceptions sind manchmal sinnvoll, um Verarbeitung von Kompositionen kontrolliert abzubrechen zB APIs mit Try oder Future. Ganze Hierarchien sind eher selten. Ob dabei die Original-Exception hilfreich ist, ist eine Einzelfallentscheidung.

Wenn ich das richtig verstanden habe, sollte man alle gefangenen Exceptions auf Verschachtelung prüfen und wenn diese besteht, bei der zu erstellenden eigenen Exception den originalen Nachrichtentext einbauen und die Ursprüngliche Exception nicht im Konstruktor verwenden.

Eine mögliche Exception ist erst einmal ein Seiteneffekt einer Methode, diese ist dann nicht mehr referentiell transparent (a.k.a. "pur"). Z.B. darf es keine Rolle spielen, welche von zwei referentiell transparenten Methoden zuerst ausgeführt wird, aber wenn Methoden Exceptions werfen, ist das natürlich nicht mehr gegeben, denn die erste Exception "gewinnt". Da referentiell transparente Methoden viele Vorteile bieten, die man im funktionalen Umfeld zu schätzen weiß (lazy evaluation, memoization u.s.w.), sollte man sich gut überlegen, ob man mit Exception arbeiten will, zumal der Mechanismus zum Catchen von Exceptionein ein nicht-lokaler Kontrollfluss (oder böse gesagt, eine leicht limitierte Form von "goto") ist, der schwer zu kontrollieren ist.

Try, Either, Option oder Validation sind dagegen ganz normale Werte, und nutzen das Typsystem, um den Rückgabewert exakt zu beschreiben (eben die Tatsache, dass es u.U. nicht möglich ist, selbigen zu bestimmen). Ich finde es irgendwie seltsam, dass sich das anstelle von Exceptions so schwer durchsetzt. Wenn eine Methode "mehrwertige" Rückgabewerte hat, schreit doch auch niemand nach einem speziellen Mechanismus, sondern man greift ganz automatisch zu Listen, Sets u.s.w.

Natürlich gibt es Stellen, wo Exceptions ihre Berechtigung haben, hauptsächlich dann, wenn die Ausnahme wirklich so schwerwiegend ist, dass man nicht angemessen reagieren kann, bei Legacy-Code (und Bibliotheken, die als solcher angesehen werden können) oder wenn dann ein Programmierfehler vorliegen muss. Wenn man aber eine komplizierte Hierarchie von verschachtelten Fehlern konstruieren will, läuft definitiv etwas falsch.