Ich habe den Code, an dem ich gerade arbeite, mit einem Java-Quellcode-Analysator analysiert. Eine der Warnungen lautet "Benutzerdefinierte Ausnahmen immer als endgültig deklarieren". Es gibt viele andere Warnungen, die nicht viel Sinn machen, aber dieser hat mich ein wenig verwirrt.
Ich arbeite an einem Framework und ich habe eine generische root-Ausnahme (z. B. FrameworkGenericException), und für andere Ausnahmen leite ich sie einfach aus der root-Ausnahme ab. Also habe ich eine Hierarchie von Ausnahmen für das Framework. Ich könnte die Hierarchie erweitern, aber diese Warnung sagt mir, dass ich keine solche Hierarchie haben soll, sondern sie individuell definieren muss. Also, was soll ich tun, was sind deine Kommentare?
Dies ist wahrscheinlich Standard-Praxis für sie: deklarieren Sie Klassen als endgültig, wenn sie nicht vererbt werden sollen, und sie denken wahrscheinlich auch, dass all Ihre Ausnahmen nicht verlängert werden.
Aber in Ihrem Fall denke ich, dass es eine gute Sache ist, eine generische Ausnahme zu machen und alle anderen davon abzugrenzen. Sag, du hast:
%Vor% Diese Ausnahmen sind Unterklassen von FrameworkException . Dann könnten Sie Ausnahmen ein wenig einfacher behandeln.
Ich würde sagen, Sie machen das Richtige, die Architektur Ihres Programms wird einfacher zu handhaben sein.
Ich habe nie von dieser Empfehlung gehört, noch ergibt es für mich einen Sinn.
Welches Werkzeug benutzen Sie? Ich habe versucht, für diese Nachricht zu googlen und habe ZERO-Hits abgesehen von deiner SO-Frage bekommen. Andere Versuche zu versuchen, die "Weisheit des Netzes auszunutzen", gab mir auch nichts offensichtlich Relevantes.
Vielleicht sollten Sie die Autoren des Code-Analyse-Tools bitten, die Gründe für diese Stilregel zu erklären ...
Die Sache ist, ein statisches Analysewerkzeug scannt im Grunde Ihren Code auf Verstöße gegen (was der Autor des Tools als "best practices" ansieht). In diesem Fall wird es in der Regel als "Best Practice" angesehen, sehr flache Ausnahmehierarchien zu verwenden.
Der Grund ist, dass es im Prinzip zwei Fälle gibt, in denen Sie eine Ausnahme bekommen. Die erste, wollen Sie die Ausnahme abfangen, weil Sie wissen, wie man damit umgeht . Zum Beispiel:
%Vor% In diesem Fall haben Sie FileNotFoundException abgefangen, weil Sie "Standarddaten" zurückgeben möchten, wenn die Datei nicht gefunden wird. In diesem Fall fangen Sie in der Regel eine spezifische Ausnahmeklasse ab - weil dies der einzige Ausnahmetyp ist, mit dem Sie umgehen können (wenn beispielsweise fetchDataFromFile eine andere Ausnahme auslöst, möchten Sie sie nicht um Standarddaten zurückzugeben.
Das andere Mal, wenn Sie Ausnahmen abfangen, ist die Wurzel Ihres Threads,
%Vor%In diesem Fall fangen Sie die Stammausnahmeklasse ab, weil Sie speziell alle Ausnahmen benötigen, damit Sie sie protokollieren oder den Benutzer benachrichtigen können.
Es gibt sehr wenige Situationen, in denen Sie etwas anderes tun müssen.
Denken Sie daran, dass dies ein statisches Analysewerkzeug ist. Es ist Aufgabe, nur "potentielle" Probleme zu melden. Wenn Sie glauben, dass Ihre Situation anders ist, dann ist die Idee, dass Sie dokumentieren, warum Sie denken, dass es anders ist und diese Warnung speziell für diesen Codeabschnitt (oder diese Klasse oder was auch immer) deaktivieren.
Ich wette, dass diese Nachricht verschwindet, wenn Sie Ihre generische Ausnahme abstrahieren. Du wirst einem anderen respektierten objektorientierten Guru folgen, Scott Meyer:
Machen Sie Nicht-Blatt-Klassen abstrakt.
Persönlich stimme ich einer Root-Ausnahme für Ihr gesamtes Framework nicht zu. Welches außergewöhnliche Verhalten hast du darin eingebettet, dass alle Kinder über das hinausgehen, was von java.lang.Throwable kommt?
Ich denke, SpecialBusinessException , die die vier Konstruktoren von java.lang.RuntimeException überschreiben, ist reichlich. Was ist der Sinn der Hierarchie? Ich wette, es ist flach und breit, mit einer Wurzelstufe. Warum stören?