Konventionen für Ausnahmen oder Fehler-codes

In high-level-Sachen, Ausnahmen; im low-level-Sachen, Fehler-codes.

Das default-Verhalten eine Ausnahme ist, sich zu entspannen, den stack und beenden Sie das Programm, wenn ich Schreibe ein Skript ein und ich gehe nach einem Schlüssel, der nicht in einem Wörterbuch ist es wahrscheinlich ein Fehler, und ich will, das Programm zu stoppen und lassen Sie mich wissen, dass.

Wenn ich allerdings Schreibe, dass ein Stück code, das ich muss wissen das Verhalten in jeder möglichen situation, dann möchte ich Fehlercodes. Ansonsten habe ich zu wissen, dass jeder Ausnahme, die geworfen werden können, indem jede Zeile in meiner Funktion zu wissen, was es tun wird (Lesen Die Ausnahme, die Geerdet einer Fluggesellschaft um eine Idee zu bekommen, wie schwierig das ist). Es ist mühsam und hart code zu schreiben, der reagiert angemessen auf jede situation (einschließlich die unglücklichen), aber das ist, weil das schreiben fehlerfreier code ist mühsam und hart, nicht, weil Sie vorbei sind Fehler-codes.

Beide Raymond Chen und Joel haben einige beredte Argumente gegen die Verwendung von Ausnahmen für alles.

Bevorzuge ich Ausnahmen, weil

• Sie unterbrechen den Fluss der Logik
• Sie profitieren von der Hierarchie der Klasse gibt, die mehr features/Funktionen
• wenn verwendet, richtig darstellen kann eine Vielzahl von Fehlern (z.B. eine InvalidMethodCallException ist auch ein LogicException, als beide treten auf, wenn ein Fehler in Ihrem code, der sollte nachweisbar sein, bevor die Laufzeit), und
• Sie können verwendet werden, zur Verbesserung des Fehlers (d.h. eine FileReadException definition der Klasse können dann die code enthalten, um zu überprüfen, ob die Datei vorhanden ist oder gesperrt ist, etc)

Ausnahmen über Fehlercodes, kein Zweifel. Sie erhalten die gleichen Vorteile von Ausnahmen, wie Sie mit Fehler-codes, aber auch viel mehr, ohne die Mängel der Fehler-codes. Die einzige klopfen an Ausnahmen ist, dass es etwas mehr Aufwand, aber in diesem Tag und Alter, das overhead sollte als vernachlässigbar angesehen werden für fast alle Anwendungen.

Hier sind einige Artikel diskutieren, den Vergleich und die Gegenüberstellung der beiden Techniken:

• Objektorientierte Exception-Handling in Perl
• Ausnahmen vs. status zurück

Gibt es einige gute links in denen, die Sie geben können, weiter zu Lesen.

Ich In der Vergangenheit trat der Fehlercode Lager (hab zu viel C-Programmierung). Aber jetzt habe ich das Licht gesehen.

Ja Ausnahmen, die sind ein bisschen eine Belastung auf das system. Aber Sie vereinfachen den code, die Verringerung der Anzahl der Fehler (und WTF-s).

Nutzen Sie also die Ausnahme, aber benutzen Sie Sie klug. Und Sie wird dein Freund sein.

Als eine Randnotiz. Ich habe gelernt, zu dokumentieren, Wann welche exception geworfen werden kann, durch die Methode. Leider ist dies nicht erforderlich, die von den meisten Sprachen. Aber es erhöht die chance, Handhabung des rechts, die Ausnahmen auf dem richtigen Niveau.

Sie sollte sowohl. Die Sache ist zu entscheiden, Wann die Verwendung jedes.

Gibt es eine wenige Fälle, in denen Ausnahmen sind die offensichtliche Wahl,:

1. In einigen Situationen Sie können nichts mit dem Fehler-code, und Sie nur behandeln müssen, dass es in einer oberen Ebene in der Aufrufliste, in der Regel melden Sie den Fehler, etwas angezeigt, um den Benutzer oder das Programm schließen. In diesen Fällen, Fehler-codes erfordern würde, Sie zu Blasen-bis die Fehler-codes manuell level um level, das ist natürlich viel einfacher zu tun, mit Ausnahmen. Der Punkt ist, dass dies für unerwartete und unhandleable Situationen.

2. Doch über die situation 1 (wo etwas unerwartetes und unhandleable passiert, nur wan nicht anmelden, es), Ausnahmen können hilfreich sein, weil Sie vielleicht hinzufügen von Kontextinformationen. Zum Beispiel, wenn ich eine SqlException in meinem unteren Ebene Daten Helfer, ich werde mich fangen wollen, dass Fehler in der low-level (wo ich weiß, der SQL-Befehl, der den Fehler verursacht hat), so kann ich erfassen, dass die Informationen und rethrow mit zusätzlichen Informationen. Bitte beachten Sie hier das Zauberwort: rethrow, und nicht schlucken.
   Die erste Regel für die Ausnahmebehandlung: nicht schlucken Ausnahmen. Beachten Sie auch, dass meine innere fangen nicht erst anmelden müssen, nichts, weil die äußeren catch wird der ganze stack-trace und melden Sie es.

3. In einigen Situationen müssen Sie eine Folge von Befehlen, und , wenn einer von Ihnen ausfallen sollten Sie Aufräumen/entsorgen Ressourcen(*), ob oder nicht, dies ist ein nicht behebbarer situation (die geworfen werden sollte) oder eine korrigierbare situation (in dem Fall, dass Sie behandeln können, die lokal oder in der Aufrufer-code, aber Sie brauchen nicht die Ausnahmen). Offensichtlich ist es viel einfacher, um alle diese Befehle in einer einzigen versuchen, statt der Prüfung Fehler-codes nach jeder Methode und Aufräumen/entsorgen im finally-block. Bitte beachten Sie, dass wenn Sie möchten, den Fehler zu sprudeln (das ist wahrscheinlich das, was Sie wollen), brauchen Sie nicht einmal brauchen, um es zu fangen - verwenden Sie einfach die schließlich für Aufräumen/entsorgen - sollten Sie nur verwenden, fangen/retrow wenn Sie möchten, fügen Sie Kontext-Informationen (siehe Punkt 2).

   Ein Beispiel wäre eine Folge von SQL-Anweisungen innerhalb einer Transaktion ausgeführt werden. Wieder, das auch ein "unhandleable" - situation, auch wenn Sie sich entscheiden, es zu fangen früh (Behandlung von lokal statt sprudelt bis an die Spitze) es ist immer noch ein fatale situation, von wo das beste Ergebnis ist abgebrochen, alles oder zumindest den Abbruch eines großen Teils des Prozesses.
   
   (*) Dies ist, wie die on error goto dass wir in alten Visual Basic -

4. In Konstruktoren kann man nur exceptions werfen.

Gesagt haben, dass, in allen anderen Situationen, bei denen Sie Rückkehr einige Informationen über die der Anrufer KANN/SOLLTE man einige Maßnahmen ergreifen, mit return-codes ist wahrscheinlich eine bessere alternative. Dies umfasst alle erwartet "Fehler", weil wahrscheinlich Sie sollten behandelt werden, indem Sie den unmittelbaren Aufrufer, und kaum werden müssen, sprudelte Sie zu viele Ebenen in dem Stapel.

Natürlich ist es immer möglich, zu behandeln erwartete Fehler als Ausnahmen, und fangen dann sofort eine Ebene nach oben, und es ist auch möglich, umfassen jede Zeile code in einem try-catch-und nehmen die Aktionen für die einzelnen möglichen Fehler. IMO, das ist schlechtes design, nicht nur, weil es viel Ausführlicher ist, aber speziell, weil die möglichen Ausnahmen, die vielleicht geworfen werden, sind offensichtlich nicht Lesen, ohne die Quellcode - und die Ausnahmen, die geworfen werden konnte, aus jeder Tiefe Methode, die Schaffung invisible gotos. Sie brechen die Struktur des Codes, indem Sie mehrere unsichtbare exit-Punkte, die den code schwer zu Lesen und zu prüfen. In anderen Worten, Sie sollten nie Ausnahmen wie flow-control, denn das wäre schwer für andere zu verstehen und zu pflegen. Es kann sogar schwierig, zu verstehen, alle möglichen code-flows für die Prüfung.

Wieder: für richtig Aufräumen/entsorgen, die Sie verwenden können, versuchen Sie es-endlich ohne Fang nichts.

Den beliebtesten Kritik über return-codes ist, dass "jemand könnte, ignorieren Sie die Fehler-codes, aber in demselben Sinne kann jemand auch schlucken Ausnahmen. Bad exception handling ist einfach in beiden Methoden. Aber das schreiben von Fehler-code-basierte Programm ist immer noch viel einfacher als das schreiben einer Ausnahme-Programm. Und wenn man aus irgendeinem Grund beschließt, Sie zu ignorieren Sie alle Fehler (auch die alte on error resume next), können Sie ganz einfach tun, dass mit der return-codes, und Sie können nicht tun, ohne eine Menge von try-catchs boilerplate.

Die zweite beliebtesten Kritik über return-codes ist, dass "es ist schwierig, bubble up" - aber das ist, weil die Menschen nicht verstehen, die Ausnahmen sind für nicht behebbare Situationen, während die Fehler-codes nicht.

Entscheidung zwischen Ausnahmen und Fehler-codes ist eine Grauzone. Es ist sogar möglich, dass Sie brauchen, um ein Fehler code aus einer wiederverwendbaren business-Methode, und dann entscheiden Sie, zu wickeln, die in eine Ausnahme (evtl. mit Zusatz-Informationen) und lass es sprudeln. Aber es ist ein design-Fehler, anzunehmen, dass ALLE Fehler geworfen werden sollte, als Ausnahmen.

Um es zusammenzufassen:

• Benutze ich gerne Ausnahmen, wenn ich eine unerwartete situation, in der es nicht viel zu tun, und wir in der Regel Abbrechen möchten, einen großen block von code oder sogar den ganzen Betrieb oder Programm. Dies ist, wie die alten "on error goto".

• Ich mag die return-codes, als ich erwartet habe, Situationen, in denen der Aufrufer-code kann/sollte man einige Maßnahmen ergreifen. Dies umfasst die meisten business-Methoden, APIs, Validierungen, und so weiter.

Dieser Unterschied zwischen Ausnahmen und Fehler-codes ist eines der design-Prinzipien der Sprache, die verwendet "Panik" für schwerwiegende unerwartete Situationen, während normale Situationen erwartet werden als Fehler zurückgegeben.

Doch zu GEHEN, ermöglicht es auch,mehrere Rückgabewerte , das ist etwas, das hilft, eine Menge über die Verwendung von return-codes, da kann man gleichzeitig einen Fehler zurück, und etwas anderes. Auf C#/Java was wir erreichen können, dass mit out-Parameter, Tupel, oder (mein Favorit) Generika, die in Kombination mit enums lassen sich klare Fehler-codes an den Anrufer:

public MethodResult<CreateOrderResultCodeEnum, Order> CreateOrder(CreateOrderOptions options)
{
    ....
    return MethodResult<CreateOrderResultCodeEnum>.CreateError(CreateOrderResultCodeEnum.NO_DELIVERY_AVAILABLE, "There is no delivery service in your area");

    ...
    return MethodResult<CreateOrderResultCodeEnum>.CreateSuccess(CreateOrderResultCodeEnum.SUCCESS, order);
}

var result = CreateOrder(options);
if (result.ResultCode == CreateOrderResultCodeEnum.OUT_OF_STOCK)
    //do something
else if (result.ResultCode == CreateOrderResultCodeEnum.SUCCESS)
    order = result.Entity; //etc...

Wenn ich einen neuen hinzufügen möglich zurück in meine Methode, ich kann sogar überprüfen Sie alle Anrufer, wenn Sie decken, die den neuen Wert in einer switch-Anweisung zum Beispiel. Kann man wirklich nicht tun, mit Ausnahmen. Wenn Sie die return-codes, werden Sie in der Regel im Voraus wissen, alle möglichen Fehler, und testen Sie für Sie. Mit Ausnahmen, die Sie in der Regel nicht wissen, was passieren könnte. Verpackung Enumerationen, die im inneren Ausnahmen (statt Generika) ist eine alternative (vorausgesetzt, es ist klar, die Art von Ausnahmen, die jede Methode wirft), aber IMO ist es immer noch schlechtes design.

Da ich die Arbeit mit C++, und haben RAII, um Sie sicher zu verwenden, ich benutze Ausnahmen fast ausschließlich. Es zieht die Fehlerbehandlung aus dem normalen Programmfluss und macht die Absicht deutlich.

Ich tun, lassen Sie Ausnahmen für außergewöhnliche Umstände obwohl. Wenn ich erwarte, dass ein bestimmter Fehler passieren eine Menge, die ich werde überprüfen, dass die operation erfolgreich sein wird, vor der Durchführung, oder rufen Sie eine version der Funktion verwendet Fehler-codes statt (Wie TryParse())

Meine überlegung wäre, wenn Sie schreiben von einem low-level-Treiber, die wirklich Leistung braucht, dann error-codes verwendet werden. Aber wenn Sie, diesen code in eine übergeordnete Anwendung, und es kann mit ein wenig Aufwand, dann wickeln Sie diesen code mit einer Schnittstelle, die überprüft, Fehlercodes und wirft Ausnahmen.

In allen anderen Fällen, Ausnahmen sind wahrscheinlich der Weg zu gehen.

Ausnahmen sind für außergewöhnliche Umständen - sprich, wenn Sie nicht Teil des normalen Fluss des code.

Es ist durchaus legitim zu mischen, Ausnahmen und Fehler-codes, wo der Fehler-codes repräsentieren den status von etwas, sondern als Fehler in der Ausführung des Codes per se (z.B. die überprüfung der return-code von einem Kind-Prozeß).

Aber, wenn ein außergewöhnlicher Umstand tritt glaube ich, Ausnahmen sind die ausdrucksstarken Modell.

Gibt es Fälle, in denen Sie lieber, oder haben, um Fehler-codes an Stelle von Ausnahmen, und diese wurden adäquat abgedeckt werden bereits bei (weitere als die anderen offensichtlichen Einschränkungen wie compiler-Unterstützung).

Aber geht in die andere Richtung, mithilfe von Ausnahmen können Sie bauen, auch höhere level-Abstraktionen für die Fehlerbehandlung, die machen den code noch ausdrucksstärker und natürlicher. Ich würde empfehlen, das Lesen dieses hervorragenden, aber unterschätzt, Artikel von C++ - Experte Andrei Alexandrescu auf das Thema, was er fordert, "Vollstreckungen": http://www.ddj.com/cpp/184403864. Obwohl es ein C++ - Artikel die Grundsätze, die allgemeingültig sind, und ich habe übersetzt die Vollstreckungen Konzept von C# Recht erfolgreich.

Ich würde es vorziehen, die Ausnahmen für alle Fehlerfälle, außer wenn ein Fehler ist eine zu erwartende bug-frei Ergebnis einer Funktion zurückgibt, die einen primitiven Datentyp. E. g. Suche nach dem index eines Teilstrings in einem größeren string würde in der Regel zurück, -1 wenn nicht gefunden, anstatt eine NotFoundException.

Rückgabe Ungültiger Zeiger, die möglicherweise aufgelöst werden (z.B. verursacht NullPointerException in Java) ist nicht akzeptabel.

Verwenden mehrere verschiedene numerische Fehlercodes (-1, -2) als return-Werte für die gleiche Funktion ist in der Regel schlechter Stil, wie Kunden möglicherweise ein "== -1" prüfen statt "< 0".

Eine Sache zu beachten hier ist die Entwicklung von APIs über die Zeit. Eine gute API erlaubt das ändern und erweitern Misserfolg Verhalten in mehreren Arten, ohne brechen Kunden. E. g. wenn ein client-Fehler-handle geprüft, für 4-Fehler-Fällen, und fügen Sie eine fünfte Fehler, den Wert Ihrer Funktion, der client-handler kann nicht testen Sie diese und brechen. Wenn Sie erhöhen, Ausnahmen, dies wird in der Regel machen es einfacher für die Kunden zur Migration auf eine neuere version einer Bibliothek.

Andere Sache zu prüfen ist, wenn in einem team arbeiten, zu zeichnen, wo eine klare Linie für alldevelopers, um eine solche Entscheidung treffen. E. g. "Ausnahmen für high-level" - Sachen, die Fehlercodes für das low-level-Zeug" ist sehr subjektiv.

In jedem Fall, in dem mehr als eine triviale Art des Fehlers möglich ist, ist der source-code sollte nie verwenden Sie das numerische literal liefern einen Fehlercode zurück oder übernehmen es (return -7, wenn x == -7,...), aber immer eine benannte Konstante (return NO_SUCH_FOO, wenn x == NO_SUCH_FOO) .

Für die meisten Anwendungen, Ausnahmen sind besser. Die Ausnahme ist, wenn die software mit anderen Geräten kommunizieren. Die Domäne, in der ich arbeite, Steuerungen in der Industrie. Hier die Fehler codes werden bevorzugt und erwartet. Also meine Antwort ist, dass es abhängig von der situation.

Meine Allgemeine Regel ist:

• Nur ein Fehler könnte angezeigt werden, die in einer Funktion: verwenden Sie Fehler-code (als parameter der Funktion)
• Mehr als einen bestimmten Fehler kommen könnte: Ausnahme auslösen