Wann benutzerdefinierte Ausnahmen vs. vorhandene Ausnahmen vs. generische Ausnahmen verwendet werden sollten

Question

Ich versuche, herauszufinden, was die richtige Form der Ausnahmen zu werfen wäre für eine Bibliothek, die ich schreibe. Ein Beispiel dafür, was ich behandeln muss, ist die Anmeldung eines Benutzers an einer Station. Dies geschieht durch Scannen eines Ausweises. Mögliche Dinge, die schief gehen könnten, sind:

• Ihr Ausweis ist deaktiviert
• Sie haben keine Erlaubnis, an diesem Bahnhof zu arbeiten.
• Der gescannte Ausweis ist nicht im System vorhanden
• Sie sind bereits an einer anderen Station angemeldet
• Die Datenbank ist ausgefallen
• Interner DB-Fehler (passiert manchmal, wenn der Ausweis nicht richtig eingerichtet wurde)

Eine Anwendung, die diese Bibliothek verwendet, muss diese Ausnahmen auf die eine oder andere Weise behandeln. Es ist möglich, dass sie einfach nur "Fehler" sagen oder dem Benutzer mehr nützliche Informationen geben wollen. Was ist die beste Vorgehensweise in dieser Situation? Für jede Möglichkeit eine eigene Ausnahme erstellen? Vorhandene Ausnahmen verwenden? Verwenden Sie Exception und geben Sie den Grund an ( throw new Exception("Badge is deactivated."); )? Ich denke, es ist eine Art Mischung aus den ersten beiden, wobei bestehende Ausnahmen verwendet werden, wo dies möglich ist, und neue erstellt werden, wo dies erforderlich ist (und Ausnahmen gruppiert werden, wo dies sinnvoll ist).

Answer 1

Ich stimme im Wesentlichen mit Ihren derzeitigen Überlegungen überein.

• Nutzen Sie gegebenenfalls bestehende Kernausnahmen: ArgumentException, InvalidOperationException, usw. Versuchen Sie nicht, Ausnahmen, die für ein anderes Modul spezifisch sind, wiederzuverwenden. Verwenden Sie die Ausnahmen, die einen klaren, generischen Zweck haben, und verwenden Sie sie nicht für Geschäftsregeln. Zum Beispiel, InvalidOperationException sollte auf einen fehlerhaften Vorgang in Bezug auf Ihre API hinweisen, nicht auf einen Verstoß gegen eine Geschäftsregel.
• Für Ausnahmen, die spezifisch für Ihre Bibliothek sind, erstellen Sie eine Basis-Ausnahmeklasse, BadgeAuthException und werfen das immer. Die spezifischen Szenarien sollten jeweils ihre eigene Unterklasse erhalten ( BadgeDeactivatedException , NoPermissionsAtWorkstationException usw.) Auf diese Weise können Anwendungen die einzelnen Unterfälle separat behandeln, wenn sie dies wünschen, aber sie können auch einfach die generische BadgeAuthException wenn sie nicht in Einzelheiten kriechen wollen.
• Was immer Sie tun, stellen Sie sicher, dass die Message Feld enthält immer nützliche Informationen, die über den Namen der Ausnahme hinausgehen.

Answer 2

Verwenden Sie Exception und geben Sie den Grund an (throw new Exception("Badge is deactivated.");)

Dies ist sicherlich eine schlechte Praxis, weil es gegen den Zweck von Ausnahmen verstößt - nicht nur eine anormale Situation zu signalisieren, sondern eine Möglichkeit zu bieten, Ausnahmen auf einer Typenebene zu unterscheiden, so dass der Benutzer eines Moduls eine Entscheidung in Abhängigkeit von einer Art von Ausnahme treffen kann.

Im Allgemeinen ist es gut, Standardausnahmen wiederzuverwenden, soweit sie abnormale Situationen, mit denen Ihr Code tatsächlich konfrontiert ist, vollständig beschreiben können. Es ist ziemlich schwierig, in einer aktuellen Situation einen Ratschlag zu geben, da Ausnahmen oft von der Semantik abhängen können (Argumentausnahme oder Ausnahme für ungültige Operationen (vielleicht geeignet für den Fall "Ihr Ausweis ist deaktiviert", zum Beispiel).

Answer 3

Es gibt zwei Arten von Ausnahmen.

Diejenigen, die spezifisch für Ihre Anwendung sind, wo es gut ist, bestehende Ausnahmen zu vermeiden.

Ihre anwendungsspezifischen Ausnahmen sollten die Anwendungsfälle für die Benutzer Ihrer Bibliotheken vereinfachen. 3 Ihrer anwendungsspezifischen Ausnahmen sind Dinge, die Benutzer tun können. Die vierte (Ausweis existiert nicht) ist eindeutig nicht prozedural, sondern viel schwerwiegender.

Es sieht so aus, als hätten Sie zwei anwendungsspezifische Fehler: benutzerorientierte Dinge und administrative Fehler.

Die anderen sind Teil einer anderen Technologie, z. B. Datenbankfehler. Sie können diese - im Allgemeinen - ignorieren. Wenn die DB nicht verfügbar ist, wird die API Fehler ausgeben und Sie können diese durch Ihre Bibliothek sprudeln lassen.

Sie können diese auch als anwendungsspezifische Ausnahme "verpacken", die eine Ausnahme auf niedrigerer Ebene enthält. Dies ist manchmal hilfreich, wenn es eine Menge untergeordneter Technologie gibt. In Ihrem Fall handelt es sich nur um eine Datenbank. Ignorieren Sie es und lassen Sie die DB-Fehler durchsprudeln.

Answer 4

Mit fein abgestuften Ausnahmeklassen, die eine gemeinsame Basisklasse erweitern, kann man fast nie etwas falsch machen. Auf diese Weise können Aufrufer, die bestimmte Ausnahmen abfangen und andere durchlassen müssen, dies tun, und Aufrufer, die alle Ausnahmen gemeinsam behandeln wollen, können dies tun.

Answer 5

Ich denke, dass Sie eine Basisausnahme und eine Subtyp-Ausnahme für jede der von Ihnen beschriebenen Situationen haben müssen (tatsächlich können Sie db down und internen db-Fehler machen, um die gleiche Basisausnahme zu haben). Der springende Punkt ist, dass es eine gute Praxis ist, Ihre eigenen Ausnahmen für Ihre Bibliothek zu haben.