___ antwort438271 ___
Ich denke, nur einen Ausnahmetyp mit einer eingebetteten Enumeration zu haben, ist suboptimal:
- Sie müssen die Ausnahme häufiger als nötig abfangen (und erneut ausführen, sobald Sie festgestellt haben, dass Sie damit nicht umgehen können)
- Das Enum selbst wird zum Hotspot für Änderungen (alle Programmierer müssen es regelmäßig ändern)
- Eine Enumeration ist nicht hierarchisch, daher können Sie beispielsweise nicht alle IO-Fehler mit einem Handler behandeln
- Manchmal möchten Sie dem Anrufer neben dem Text der Fehlermeldung auch weitere Informationen zur Verfügung stellen, z. der Pfad der Datei, die nicht gefunden wurde oder die Fehlernummer, die vom SQL-Server empfangen wurde. Wenn Sie solche zusätzlichen Informationen aus allen möglichen Fehlerszenarien in dieselbe Ausnahme einfügen, wird die Handhabung noch mühsamer.
Um Ihre Frage zu beantworten, verwende ich eine Hierarchie von Ausnahmen. Es ist viel breiter als tief.
___ qstnhdr ___ Ausnahmehierarchie und Fehleraufzählung
___ answer438365 ___
Ich denke, Sie haben das Schlimmste aus zwei Welten. Eine große Ausnahmehierarchie ist nutzlos, da Clients bekanntermaßen faul sind und am Ende nur nach den obersten Knoten suchen (möglicherweise nur für den Hierarchiestamm). Ihr Enum-System löst dieses Problem nicht und sorgt für ein umständlicheres Ausnahmesystem.
Wenn Sie wirklich wissen, dass viele verschiedene Ausnahmen benötigt werden und Catcher die verschiedenen Ausnahmen wirklich wollen (wissen, nicht vage denken), fahren Sie mit der großen Hierarchie fort und vergessen Sie die Enums. Ansonsten bleibe bei der kleinen Exception-Hierarchie und biete nur die Exception-Klassen an, die für Catcher wirklich interessant sind.
___ answer438279 ___
Meiner Erfahrung nach werden zu viele Ausnahmeklassen nur verwirrend, vor allem weil sie nur für sehr spezifische Problemtypen verwendet werden. Ich habe ein System gesehen, bei dem jede Fehlerbedingung eine eigene Ausnahme hatte, aber nur die Super-Klassen wurden in den Catch-Blöcken überprüft. Die Unterklassen waren eine völlige Zeitverschwendung.
Wenn Sie andererseits nach der Enumeration suchen und die Ausnahme erneut auslösen möchten, ist der Code weniger intuitiv, da Sie die Ausnahme, die direkt nach dem Catch geworfen wird, nicht identifizieren können. Vielleicht nur ein kleiner Nachteil, aber wenn es oft verwendet wird, kann es sich auf die Lesbarkeit auswirken. Es könnte auch ein Leistungsproblem darstellen, wenn es in Code verwendet wird, der sehr schnell sein muss.
Ich würde die Enum-Lösung nicht verwenden, sondern ein paar Ausnahmetypen, die ein ausreichend breites Spektrum haben, um nützlich zu sein. Wie eine DatabaseException anstelle mehrerer Ausnahmen wie TableNotFoundException, ColumnNotFoundexception usw. Meiner Erfahrung nach funktioniert das am besten für die meisten Entwickler. Sie können jederzeit ein Feld mit einem Fehlercode hinzufügen, den Sie dem Benutzer anzeigen, um die Kommunikation zwischen Benutzer und Support zu vereinfachen.
___ answer438352 ___
Sie lösen nicht das Problem von zu vielen Ausnahmeklassen, indem Sie sie durch einen Ausnahmetyp und Aufzählungssubtypen ersetzen. In der Tat, Sie machen es nur schlimmer!
Beispiel: Angenommen, Sie hatten die Ausnahmetypen Ex1..Ex99, z. E14..E18 sind Childs von E1, usw. Sie entscheiden sich nun, sie durch eine Ausnahme Ex und Subtypen ST1..ST99 zu ersetzen. Was hast du gelöst? Nichts - die Menschen müssen immer noch mit allen Möglichkeiten umgehen. Was hast du schlimmer gemacht? Sie können ST14-ST18 nicht ignorieren und sie als Vorkommnisse von ST1 behandeln. Sie müssen jetzt alle 99 Möglichkeiten behandeln, da Sie Enum-Subtypen keine natürliche, flexible Hierarchie haben.
___ answer438460 ___
Verwechseln Sie Fehler nicht mit Ausnahmen.
Fehler passieren, lösen sie so nah wie möglich an das Problem.
Ausnahmen sind selten und in der Regel nicht ohne weitere kontextuelle Informationen lösbar.
Wenn etwas schief geht und lokal korrigiert werden kann, sollten Sie wahrscheinlich Fehlercodes verwenden und sie dort und dann behandeln.
Ausnahmen sollten verwendet werden, um das Problem im Aufruf-Stack auf einen Kontext zu übertragen, der genügend Informationen zur Lösung des Problems enthält.
Sprich: Enums sind nicht der richtige Weg, da sie den gesamten try-catch-Mechanismus umgehen, den der Compiler automatisch für Sie generiert.
___ qstntxt ___
Ich habe irgendwo gelesen (ich kann es jetzt nicht finden), dass große Ausnahmehierarchien Zeitverschwendung sind. Die Begründung für diese Aussage schien zu der Zeit stichhaltig und die Idee blieb bei mir.
In meinem eigenen Code, wenn ich eine Codebasis habe, die eine Reihe von Fehlerbedingungen haben kann, verwende ich eine einzelne Ausnahme mit einem Aufzählungselement, um zwischen ihnen zu unterscheiden.
Wenn der Fall auftaucht, dass ich einen dieser Fehler auffangen muss, fange ich ihn, überprüfe das Enum und wiederhole es, wenn es nicht das ist, was ich erwartet habe. Im Idealfall sollte dies selten sein.
Ich habe wieder mit Ausnahmen gearbeitet, und ich hatte einen besinnlichen Moment, in dem ich meine Ausnahmegewohnheiten in Frage stellte. Ich bin gespannt was alle anderen machen und warum?
Hierarchie oder eine Ausnahme mit Datenmembern.
Übrigens, ich gehe davon aus, dass Sie mit der Idee von Ausnahme- und Fehlercodes einverstanden sind. Ich möchte diese Dose Würmer nicht öffnen.
___ tag123c ___ C ++ ist eine universelle Programmiersprache. Es wurde ursprünglich als Erweiterung von C entworfen und behält eine ähnliche Syntax, ist aber jetzt eine komplett andere Sprache. Verwenden Sie dieses Tag für Fragen zu Code, der mit einem C ++ - Compiler kompiliert werden soll.
___ antwort438258 ___
Ich mag die Idee, eine kleine Anzahl von Ausnahmen für verschiedene Fehlerklassifizierungen zu haben, beispielsweise für fatale / nicht-fatale Bedingungen oder für bestimmte Schichten oder Module einer App. Der Werfer der Ausnahme sollte dann Codes bereitstellen, die die Ausnahme als Nutzlast enthalten. Die Präsentationsschicht der Anwendung kann lokalisierte, menschenlesbare Fehlermeldungen entsprechend den Codes nachschlagen.
Zusammenfassend sind Ausnahmetypen für den Entwickler nützlich und Nachrichten, die Fehlercodes entsprechen, sind für den Benutzer nützlich.
___ answer438797 ___
Einfache Faustregel:
- Wenn Sie nach dem Untersuchen Ausnahmen erneut auslösen, benötigen Sie eine feingliedrigere Ausnahmehierarchie (mit Ausnahme des seltenen Falls, in dem die Prüfung eine erhebliche Logik mit sich bringt).
- Wenn Sie Exception-Klassen haben, die niemals abgefangen werden (nur ihre Supertypen sind), dann brauchen Sie eine weniger feingliedrige Exception-Hierarchie.
___ tag123exception ___ Eine Ausnahme ist eine ungewöhnliche Bedingung, die eine Abweichung vom normalen Ablauf des Programms erfordert. Normalerweise sollte eine Ausnahme nicht zu einem Totalausfall führen, sondern stattdessen von einem Ausnahmebehandler begleitet werden. Die Ausnahmebehandlung ist ein eingebautes Konstrukt in vielen Programmiersprachen. In der Regel werden Ausnahmen behandelt, indem der Stapel abgewickelt wird und somit in einen definierten Zustand außerhalb des Gültigkeitsbereichs der Ausnahme zurückversetzt wird und dann ein Verarbeitungsblock oder eine Routine aufgerufen wird.
___ antwort438801 ___
Sie sollten nicht dogmatisch sein. Verwenden Sie, was am besten für das Problem in der Hand passt. Meine Faustregel dafür lautet wie folgt:
- Erstellen Sie neue Ausnahmeklassen nur, wenn Sie eine Ausnahme benötigen, die ein anderes Verhalten erfordert.
- Fügen Sie stattdessen Ausnahmeklassen Inhalte (enums, errorcodes, was auch immer) hinzu, wenn Sie einfach zusätzliche Informationen in der Ausnahme
benötigen
- Erstellen Sie keine neuen Klassen, es sei denn, Sie benötigen sie wirklich. Und denk daran, YAGNI ...
___