Ich habe eine Klasse geschrieben, die Konfigurationsobjekte meiner Anwendung lädt und verfolgt, so dass ich Änderungen einfach ausschreiben oder die gesamte Konfiguration auf einmal mit einem einzigen Methodenaufruf laden kann. Jedes Konfigurationsobjekt kann jedoch möglicherweise eine Ausnahme auslösen, wenn IO ausgeführt wird, aber ich möchte nicht, dass diese Fehler den gesamten Prozess abbrechen, damit die anderen Objekte noch eine Chance zum erneuten Laden / Schreiben erhalten. Deshalb sammle ich alle Exceptions, die beim Iterieren über die Objekte ausgelöst werden, und speichere sie in einer Super-Exception, die nach der Schleife geworfen wird, da jede Exception noch behandelt werden muss und jemand darüber informiert werden muss, was genau falsch gelaufen ist. Dieser Ansatz erscheint mir jedoch etwas merkwürdig. Jemand da draußen mit einer saubereren Lösung?
Hier ist ein Code der erwähnten Klasse:
%Vor%Wenn Sie die Ergebnisse der Operationen behalten wollen, die Sie tun, als Sie absichtlich weitermachen, dann ist das Auslösen einer Ausnahme das Falsche. Generell sollten Sie darauf achten, nichts zu stören, wenn Sie eine Ausnahme auslösen.
Ich schlage vor, dass Sie die Exceptions oder Daten, die von ihnen abgeleitet wurden, an einen Fehlerbehandlungs-Callback weitergeben, während Sie fortfahren.
%Vor%Es gibt Leitprinzipien beim Entwerfen, was und wann Ausnahmen ausgelöst werden sollten, und die zwei relevanten für dieses Szenario sind:
Die Art und Weise, wie Sie StoreException in MultipleCauseException übersetzen, erscheint mir vernünftig, auch wenn verschiedene Ausnahmetypen in einen zusammengefasst werden, ist das vielleicht nicht die beste Idee. Leider unterstützt Java das generische Throwable s nicht, also ist vielleicht die einzige Alternative, eine separate MultipleStoreException Unterklasse zu erstellen.
Im Hinblick darauf, Ausnahmen so früh wie möglich zu werfen (was Sie NICHT tun), werde ich sagen, dass es in Ordnung ist, die Regel in bestimmten Fällen zu beugen. Ich empfinde die Gefahr, einen Wurf zu verzögern, wenn außergewöhnliche Situationen unnötigerweise in eine Kettenreaktion eingreifen. Wann immer dies möglich ist, möchten Sie dies vermeiden und die Ausnahme auf den kleinsten möglichen Umfang lokalisieren.
Wenn es in Ihrem Fall sinnvoll ist, das Speichern von Ressourcen als mehrere unabhängige Aufgaben zu betrachten, dann ist es vielleicht in Ordnung, die Ausnahme so zu "verarbeiten", wie Sie es getan haben. In anderen Situationen, in denen die Aufgaben eine kompliziertere Abhängigkeitsbeziehung haben, wird es jedoch die Aufgabe, die Ausnahmen zu analysieren, schwieriger, sie zusammenzufassen.
In einem abstrakteren Sinn, in der Graphentheorie, denke ich, dass es in Ordnung ist, einen Knoten mit mehreren kinderlosen Kindern zu einem zusammenzufassen. Es ist wahrscheinlich nicht in Ordnung, einen ganzen großen Teilbaum oder, schlimmer noch, einen zyklischen Graphen in einen Knoten zusammenzufassen.
Tags und Links java exception-handling