Good Practices für die Behandlung von Java-Ausnahmen

Question

Ich habe einige Fragen bezüglich der Behandlung von Ausnahmen in Java. Ich habe ein bisschen darüber gelesen und einige widersprüchliche Richtlinien bekommen.

Best Practices for Exception Handling

die durch die erwähnten Artikel gehen lassen:

Darin heißt es, dass man in der Regel wenn „Client-Code kann nichts tun“ mit geprüften Ausnahmen vermeiden sollte. Aber was genau bedeutet das? Wird in der GUI eine Fehlermeldung angezeigt, die einen Grund für das Überspringen der geprüften Ausnahme bietet? Aber es würde den GUI-Programmierer zwingen, sich daran zu erinnern, RuntimeExceptions und ihre Nachkommen zu erfassen, um potentielle Fehlerinformationen anzuzeigen.

Die zweite in diesem Artikel vorgestellte Ansicht ist, dass man sich die Erfindung eigener Ausnahmeklassen entziehen sollte, es sei denn, ich möchte einige Zollfelder/Methoden in ihnen implementieren. Im Allgemeinen stimme ich damit nicht überein, meine Praxis heute war genau das Gegenteil: Ich habe Ausnahmen in meiner eigenen Ausnahmestruktur zu Reflexzielen zusammengefasst, die von Klassen realisiert wurden, die ich schreibe, auch wenn sie Exception erweitern, ohne neue Methoden hinzuzufügen. Ich denke, es hilft, sie in den höheren Schichten flexibler zu handhaben, wenn sie geworfen werden, und es ist im Allgemeinen klarer und verständlicher für Programmierer, die diese Klassen verwenden werden.

Ich implementierte einige Code heute 'neue Art' in dem Artikel präsentiert wirft RuntimeException hier und da, dann lasse ich Sonar analysieren. Um mich noch mehr zu verwirren, markierte Sonar meine RuntimeExceptions als Major errors mit einer Nachricht wie "Vermeiden Sie Root-Ausnahmen zu werfen, wrap'em in Ihren eigenen Typen".

So sieht es ziemlich kontrovers aus, was denkst du?

Ich habe auch von einem der heutigen Tech-Leads gehört, dass das Auspacken von Ausnahmen schlecht ist, "weil es für JVM eine wirklich kostspielige Operation ist". Für mich, auf der anderen Seite werfen SQLExceptions oder IOExceptions überall sieht aus wie ein bisschen kaputt Kapselung.

Also was ist Ihre allgemeine Einstellung zu Fragen, die ich hier vorgestellt?

1. Wenn Ausnahmen in meiner eigenen Art wickeln, wenn ich soll das nicht tun?

2. Wo dieser Punkt von ‚Client kann nichts dagegen tun, werfen Runtime-Ausnahme? '

3. Was ist mit Leistungsproblemen?

Answer 1

Es sieht aus wie Ihre Tech-Blei, wie oft seine Rolle Entwickler entgangen ist, weil er es nicht gut war.

würde meine Ratschläge sein:

• Laufzeit Ausnahmen überprüft Ausnahmen bevorzugen, vor allem, wenn Sie nicht der einzige Client Ihrer API sind. Die Verwendung einer geprüften Ausnahme zwingt jeden Client, die Ausnahme zu behandeln, auch wenn sie nichts dagegen tun kann. Wenn dies wirklich das ist, was Sie tun möchtenden Anrufer zwingen, damit umzugehen), dann ist eine geprüfte Ausnahme das, was Sie wollen.
• Wenn das einzige, was der Client tun kann, wenn eine Ausnahme auftritt, ist eine mehr oder weniger allgemeine Fehlermeldung wie "oops, etwas Schlimmes passiert, bitte versuchen Sie es erneut oder gehen Sie zurück zur Begrüßungsseite". Die meisten Präsentationsframeworks bieten eine Möglichkeit, einen generischen Fehlerhandler zu verwenden.
• verwenden Sie definitiv Ausnahmen, die mit Ihrer Abstraktionsschicht verknüpft sind. Das Übernehmen einer SQLException von einem High-Level-Service ist nicht ausreichend. Verwenden Sie vorhandene Ausnahmetypen, wenn sie geeignet sind (wie IllegalArgumentException, um ein ungültiges Argument zu signalisieren). Andernfalls packen Sie die Ausnahme auf niedriger Ebene in einen geeigneten Ausnahmetyp auf höherer Ebene. Was teuer ist, ist eine Ausnahme auszulösen. Ob es sich um einen anderen handelt oder nicht, spielt keine große Rolle. Und das sollte nur ausnahmsweise passieren.