Ausnahmebehandlung

stimmen
2

Ist Structured Exception Handling schlecht? Was ist der richtige Weg, um Ausnahmen zu behandeln?

EDIT: Ausnahmebehandlung in .NET C #.

Ich habe in der Regel eine Reihe von spezifischen Ausnahmeklassen (DivideByZeroException, ArrayTypeMismatchException) und haben keine allgemeine „catch (Exception ex)“.

Der Gedanke dahinter ist, dass ich bestimmte Arten von Ausnahmen auftreten und haben spezifische Maßnahmen definiert erwarten, wenn sie auftreten, und die unerwarteten Ausnahmen, die die Schnittstelle (entweder Fenster oder Web) würden steigen. Ist das eine gute Praxis?

Veröffentlicht am 09/12/2008 um 15:31
quelle vom benutzer
In anderen Sprachen...                            


5 antworten

stimmen
6

Ich bin mir nicht sicher, was Sie durch ‚strukturierte Ausnahmebehandlung‘ bedeuten.

Das Schlimmste, was in Ausnahmebehandlung durchgeführt werden kann, ist die Ausnahme zu ‚schlucken‘ oder es still zu behandeln.

Mach das nicht:

try {
   ...
}
catch (Exception e) {
   //TODO: handle this later
}

Dies wird sehr oft aus Faulheit getan Code zu kompilieren. Wenn Sie nicht wissen, wie die Ausnahme auf einer bestimmten Ebene zu behandeln, hat die Methode die Ausnahme auslösen und zumindest einen Haken alle Handler an der Spitze. Ihr Feedback irgendwie (über die GUI, eine Seite / E-Mail an ein Support-Mitarbeiter, Protokolldatei), so dass das Problem schließlich repariert werden. Schweigend fängt später auf eine Ausnahme führt fast immer zu einem größeren Problem geschieht, und es schwer zu verfolgen ist.

Beantwortet am 09/12/2008 um 15:39
quelle vom benutzer

stimmen
3

Catch-Anweisungen + Stack-Traces. Nicht immer eine Ausnahme fangen, ohne einen Stack-Trace Drucken Sie oder jemand anderes haben, dass Code zur Kasse wieder verschließen und Stack-Traces im Catch-Block, wenn ein Fehler auftritt und Ihre Log-Dateien sind entweder leer oder vage.

Beantwortet am 09/12/2008 um 15:33
quelle vom benutzer

stimmen
1

Dies ist ein komplexes Thema ... gibt es Bücher zu diesem Thema ... aber ... Es gibt zwei Hauptarten von Ausnahmebehandlung ... inline, wo Code mit möglichen Fehlern umgehen ist inline mit dem Code, der ein Verfahren oder eine Routine würde „normal“ auszuführen und strukturierte Ausnahmebehandlung, wo der Code anderer Stelle ist, und Teh Infrastruktur ausgelegt ist automatisch in diesem Ausnahmebehandlungscode switych wenn ein unerwartetes Ereignis (ein Fehler) tritt ... Beide haben advantedges und disadvanteges. Der „Inline“ Ansatz neigt dazu, Code zu erzeugen, die viel mehr überladen ist (mit dem Fehlercode) und schwerer zu lesen und zu pflegen. Aber es ist einfacher zu produzieren vorne, da es erfordert keine Vorabanalyse, beim Umgang mit mit Inline-Fehlern, man oft Methoden zurückzukehr boolean oder numerisch „Fehler“ Codes, indiocating an den Anrufer, ob die metjhod oder Routine erfolgreich war. Dadurch entfällt die „funktional“ Syntax eine Routine „Rückkehr“ einen sinnvollen Mehrwert oder Objekt ist, (da jede Funktion durch Konvention muss einen Fehlercode zurück) Wenn die strukturierte Ausnahmebehandlung verwendet wird, diese Frage ist strittig.

Die strukturierte Ausnahmebehandlung, OTOH im Allgemeinen härter gut zu machen, wie es Front-Analyse, was Fehler eine Routine oder ein Verfahren erfordert könnte möglicherweise produzieren, und das, was das Verfahren oder über jeden Fehler tun soll, wenn sie auftritt.

Eines ist sicher, nicht mischen die beiden Ansätze in einer einzigen Komponente ...

Beantwortet am 09/12/2008 um 15:59
quelle vom benutzer

stimmen
1

Meine Empfehlung:

Verwenden Sie keine Ausnahme fangen, es sei denn:

  • Geschieht dies nicht, so würde die Anwendung (zB in einem Event-Handler) zum Absturz
    • Und in dieser Situation sollten Sie die Ausnahme protokollieren, so dass Sie wissen, was passiert ist und wenn
  • Sie können etwas tun, um zu versuchen, die Situation zu beheben (zB einen Wiederholungsmechanismus Implementierung, wenn eine externe API aufrufen, die gelegentlich eine Ausnahme auslöst (beachten Sie, dass die Ausnahmebehandlung sollte nicht verwendet werden, um Steuerung des Programmablaufs))
    • Und in dieser Situation fangen nur die spezifische Ausnahme Typ, den Sie zu bekommen geworfen erwarten

Fangen Sie die Ausnahme auf dem höchstmöglichen Niveau bedeutet, dass Sie den maximalen Call-Stack erhalten, was sehr nützlich ist, wenn man durch die Protokolle geht und zu versuchen, zu sehen, was erste Aktion die Abfolge von Ereignissen ausgelöst, die in erster Linie auf die Ausnahme geführt .

Beantwortet am 09/12/2008 um 15:45
quelle vom benutzer

stimmen
0

Ich bin keine Windows-Programmierer, aber es scheint mir, dass die strukturierte Ausnahmebehandlung unter Verwendung von Hardware-Ausnahmen wie Software-Ausnahmen zu behandeln, bedeutet, dass:

  • Ihr Code tut etwas, das in der C ++ Standard nicht definiert oder die Implementierung definiert produziert Verhalten (wie zB Division durch Null).
  • Windows legt fest, dass mit SEH aktiviert werden, damit eine Ausnahme in diesem Fall wirft.
  • Sie verwenden diese Tatsache die Ausnahme zu fangen und / oder einen Abschluss Handler auszuführen.

So sind die Fragen zu stellen, IMO, sind:

  • Ist Ihre Aufgabe in der Programmierung wirklich von der Art, daß Standard-C ++ nicht verarbeiten kann? (Oder nur in einer Art und Weise handhaben, die zu messbar schlechter ist, was Sie erhalten, indem die Hardware Ausnahme erlaubt).
  • Haben Sie wirklich brauchen, Maßnahmen zu ergreifen, wenn Ihr Code Nicht-Standard geht?
  • Können Sie Ihren Code schreiben, so dass es keine Hardware-Ausnahmen in erster Linie provozieren?

Wenn die Antworten ‚Ja‘, ‚Ja‘, ‚Nein‘, dann strukturierte Ausnahmebehandlung erforderlich ist. Ansonsten können Sie in der Lage sein, es zu vermeiden, in diesem Fall sind Sie wahrscheinlich zu wollen. Schreiben Ausnahme-sichere Code ist schwierig, so desto stärker ist die Ausnahme garantiert können Sie das besser anbieten. Code, der vielleicht durch Null mit SEH teilt sich die nothrow Garantie nicht anbieten, wenn vielleicht mit ein bisschen Redesign, so dass Anrufer geben Sie es nicht nutzlose Daten, könnte es tun. Aber wenn eine Funktion bereits aus anderen Gründen Ausnahmen werfen, dann möglicherweise auch sie für Hardware-Fallen werfen könnten Dinge nicht noch schlimmer machen.

Ein bemerkenswerter Sonderfall ist die Speicherzuordnung. Nicht sicher , ob .NET tut dies aber auf Linux Zuordnung nicht nur , wenn es nicht genügend virtueller Adressraum für die Zuordnung. Physikalischer Speicher wird bei der ersten Verwendung begangen, und verursacht eine Hardware-Ausnahme , wenn es nicht genug ist. Da die Speicherzuweisung sollte std :: bad_alloc bei einem Fehler werfen, und die Umsetzung scheitert diese Forderung der Norm zu implementieren, es kannsein, das zu tun in einigen Fällen die Hardware Ausnahme von Software ist die richtige Sache zu konvertieren. Jedoch kann diese Hardware-Ausnahme an unerwarteten Stellen auftreten, (einschließlich in Routinen haben Sie waren nothrow), so kann immer noch unmöglich sein, anmutig zu handhaben, weshalb Linux-Kern statt werfen Dumps. In der Praxis alles, was voll Konstruktor stürzt initialisiert wird, die auf die Zuweisung oft nahe genug ist, dass eine Software-Ausnahme statt nützlich wäre.

Beantwortet am 09/12/2008 um 16:06
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more