Ich arbeite an einem Legacy-System mit einer benutzerdefinierten Ausnahme, die gosh-frickity-überall verwendet wird. Es wurde von der ServletException -Klasse inspiriert, die sagte "Nun, jedes Mal, wenn Sie eine Ausnahme in Ihrem Servlet haben, wollen Sie diese ServletException " werfen.
Mit der Entwicklung des Systems (über 10 Jahre) hat ein robusteres System zum Abfangen der Ausnahmen auf einer höheren Ebene stattgefunden, und es ist nicht länger notwendig, jede Ausnahme in diese benutzerdefinierte Ausnahme zu verpacken. (Man könnte argumentieren, dass es das nie war, aber das ist eine andere Geschichte. Es ist eine stabile App, also täusche ich mich nicht zu sehr !!) Aber wir werden sie nicht alle auf einmal umgestalten, nur langsam im Laufe der Zeit. p>
Eine Sache, die die Zukunft vereinfachen würde, wäre jedoch, wenn die benutzerdefinierte Ausnahme eine Laufzeitausnahme anstelle einer geprüften Ausnahme wäre. Auf diese Weise müssen wir sie nicht überall explizit abfangen, und Legacy-Code, der noch nicht refaktoriert wurde, wird weiterhin genauso ausgegeben, wie sie eine Nullzeiger-Ausnahme auslösen würde, falls eine solche auftritt.
Meine Frage ist ... Was sind die Nebenwirkungen einer einmal geprüften Ausnahme, die zu einer Laufzeitausnahme wird?
Ich kann mir keine vorstellen, abgesehen von Warnungen für unnötige Überprüfung und Würfe, aber es wäre nett, von jemandem, der diesen Weg schon einmal gegangen ist, etwas zu erfahren.
Das Ändern einer geprüften Ausnahme in eine ungeprüfte Ausnahme hat sehr wenig praktische Auswirkungen auf existierenden, funktionierenden Code, aber Sie müssen auf die Möglichkeit achten, dass Sie irgendwo in Ihrem Code catch (RuntimeException ...) haben. Solche Fänge fangen Ihre benutzerdefinierte Ausnahme jetzt nicht ab, aber sie würden es tun, wenn Sie sie nicht aktivieren.
Sie könnten auch auf Probleme stoßen, wenn Sie etwas tun, das sich auf Methoden bezieht, die diese Ausnahme auslösen (was anscheinend die meisten sind).
So etwas passierte auf einem alten Modul einer App, die ich pflegen musste. Das einzige Problem beim Übersetzen von Ausnahmen in Runtime ist, dass Sie die Granularität verlieren, aber das liegt ganz bei Ihnen.
Zum Beispiel hatten wir eine Menge Code in den tieferen Schichten:
%Vor%Wir haben dieses Muster achtlos über die ganze Ebene hinweg verwendet, und wenn wir die Ursache der Ausnahme überprüfen mussten, mussten wir immer die Ursache für die Ausnahme finden, und das hat in höheren Ebenen eine Menge Vortex gemacht. Bis heute glaube ich, dass es besser ist, eine gute Klassenhierarchie von nicht geprüften Ausnahmen zu erstellen, um die Granularität zu erhalten. z.B.
%Vor%Und damit können Sie die Ausnahme in anderen Layern leicht abfangen und Fehler und Fallbacks leicht teilen:
%Vor%Hier sind einige, an die ich denken kann
Als allgemeine Daumenregel meiner Meinung nach:
Tags und Links java runtimeexception