Frage

Ich war in beiden Situationen:

  • Es werden zu viele benutzerdefinierte Ausnahmen erstellt
  • Es werden zu viele allgemeine Ausnahmeklassen verwendet

In beiden Fällen startete das Projekt gut, wurde aber bald zu einem Mehraufwand für die Wartung (und Umgestaltung).

Was ist also die beste Vorgehensweise bei der Erstellung eigener Ausnahmeklassen?

War es hilfreich?

Lösung

Die Java-Spezialisten schrieb einen Beitrag darüber Ausnahmen in Java, und darin werden einige „Best Practices“ zum Erstellen von Ausnahmen aufgeführt, die im Folgenden zusammengefasst sind:

  • Schreiben Sie keine eigenen Ausnahmen (es gibt viele nützliche Ausnahmen, die bereits Teil der Java-API sind)

  • Schreiben Sie nützliche Ausnahmen (wenn Sie Ihre eigenen Ausnahmen schreiben müssen, stellen Sie sicher, dass diese nützliche Informationen über das aufgetretene Problem enthalten)

Andere Tipps

Tun Sie nicht das, was die Entwickler in meiner Firma getan haben.Jemand hat eine [sic] InvalidArgumentException erstellt, die mit java.lang.IllegalArgumentException vergleichbar ist, und wir verwenden sie jetzt in (buchstäblich) Hunderten von Klassen.Beides weist darauf hin, dass einer Methode ein illegales oder unangemessenes Argument übergeben wurde.Sprechen Sie über eine Verschwendung...

Joshua Bloch behandelt dies in Effektiver Leitfaden zur Java-Programmiersprache [meine erste Bibel zum Thema Best Practices] Kapitel 8.Ausnahmen Punkt 42:Bevorzugen Sie die Verwendung von Standardausnahmen.Hier ist ein Teil von dem, was er sagt:

Die Wiederverwendung bereits vorhandener Ausnahmen hat mehrere Vorteile.Vor allem macht es Ihre API einfacher zu erlernen und zu verwenden, weil Es entspricht etablierten Konventionen, mit denen Programmierer bereits vertraut sind [meine Betonung, nicht die von Bloch].Ein knapper zweiter Punkt ist, dass Programme, die Ihre API verwenden, einfacher zu lesen sind, da sie nicht mit unbekannten Ausnahmen überladen sind.Schließlich bedeuten weniger Ausnahmeklassen einen geringeren Speicherbedarf und weniger Zeitaufwand für das Laden von Klassen.

Die am häufigsten wiederverwendete Ausnahme ist IllegalArgumentException.Dies ist im Allgemeinen die Ausnahme, die ausgelöst wird, wenn der Aufrufer ein Argument übergibt, dessen Wert ungeeignet ist.Dies wäre beispielsweise die auszulösende Ausnahme, wenn der Aufrufer eine negative Zahl in einem Parameter übergibt, der angibt, wie oft eine Aktion wiederholt werden soll.

Das heißt, das sollten Sie tun niemals löst selbst eine Ausnahme aus.Java verfügt über eine sorgfältig ausgewählte, vielfältige und zielgerichtete Reihe integrierter Ausnahmen, die die meisten Situationen abdecken UND Beschreiben Sie die aufgetretene Ausnahme so gut, dass Sie die Ursache beheben können.

Seien Sie freundlich zu den Programmierern, die Ihren Code in Zukunft pflegen müssen.

Meine Faustregel lautet: Wenn der Client (der Aufrufer) je nach Art der ausgelösten Ausnahme vernünftigerweise etwas anderes tun möchte, sind die zusätzlichen Ausnahmetypen gerechtfertigt.In den meisten Fällen werden die zusätzlichen Ausnahmetypen jedoch nicht benötigt.Zum Beispiel, wenn der Anrufer Code wie schreibt

try {
     doIt();
} catch (ExceptionType1 ex1) {
     // do something useful
} catch (ExceptionType2 ex2) {
     // do the exact same useful thing that was done in the block above
}

Dann werden die zusätzlichen Ausnahmetypen offensichtlich nicht benötigt.Allzu oft sehe ich Code wie diesen (oder bin gezwungen, ihn zu schreiben), weil der aufgerufene Code übereifrig neue Ausnahmetypen erstellt hat.

Wenn ich keine Ausnahme finden kann, deren Name beschreibt, welche Art von Fehler verursacht wurde, erstelle ich eine eigene.

Das ist meine Faustregel.

Grundsätzlich verdient jeder Job eine eigene Ausnahme.Wenn Sie Ausnahmen abfangen, unterscheiden Sie nicht verschiedene Instanzen, wie Sie es normalerweise bei Objekten tun würden, daher benötigen Sie unterschiedliche Untertypen.Die Verwendung zu vieler benutzerdefinierter Ausnahmen ist ein Fall, der meiner Meinung nach kaum vorkommt.

Ein Rat wäre, bei Bedarf Ausnahmen zu erstellen. Wenn sich herausstellt, dass ein Ausnahmetyp ein Duplikat eines anderen ist, überarbeiten Sie den Code, indem Sie die beiden zusammenführen.Natürlich hilft es, wenn man sich von Anfang an Gedanken über die Strukturierung von Ausnahmen macht.Im Allgemeinen sollten Sie benutzerdefinierte Ausnahmen jedoch für alle Fälle verwenden, in denen keine 1:1-Entsprechung zu vorhandenen, situationsspezifischen Ausnahmen besteht.

Andererseits, NullPointerExceptions und IndexOutofBoundsExceptions könnte eigentlich oft angebracht sein.Fangen Sie diese jedoch nicht ab (außer bei der Protokollierung), da es sich um einen Programmierfehler handelt, was bedeutet, dass sich das Programm nach dem Auslösen in einem undefinierten Zustand befindet.

Meine eigene Faustregel:

Ich werfe nie eine Ausnahme aus, außer bei Unit-Tests, wenn das, was Sie auslösen, irrelevant ist und es keinen Grund gibt, zusätzliche Zeit damit zu verbringen.

Ich erstelle meinen eigenen benutzerdefinierten Ausnahmetyp für Fehler, die in meiner benutzerdefinierten Geschäftslogik auftreten.Dieser Ausnahmetyp wird so weit wie möglich für die Neuformulierung anderer Ausnahmen verwendet, außer in Fällen, in denen es für den Client sinnvoll ist, Einblick in die tatsächlich aufgetretenen Ereignisse zu haben.

Beim Erstellen Ihrer eigenen Ausnahme:

  • Alle Ausnahmen müssen ein untergeordnetes Element von sein Wurfbare Klasse

  • Wenn Sie eine geprüfte Ausnahme schreiben möchten, die automatisch durch die Handle- oder Declare-Regel erzwungen wird, müssen Sie die erweitern Ausnahmeklasse

  • Wenn Sie eine Laufzeitausnahme schreiben möchten, müssen Sie die Laufzeitausnahmeklasse erweitern.

Iss keine Ausnahmen, wirf sie https://stackoverflow.com/a/921583/1097600

Vermeiden Sie es, eine eigene Ausnahme zu erstellen.Verwenden Sie die folgenden, die bereits vorhanden sind.

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

Ungeprüfte Ausnahmen auslösen.

Beispiel

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top