Suche klares Konzept für die Fehlerbehandlung in C#

Hallo,

für die Verwaltung von Fehlern habe ich in meiner Software bisher nie ein schlüssiges Konzept gehabt. Mal gaben die Methoden einen Fehlercode als Rückgabewert zurück. Mal lösten sie eine Exception aus. Aufrufende Methoden unterdrückten dann die Exception entweder, werteten sie aus oder gaben sie an die nächsthöhere Methode weiter. Es fehlte aber ein klares System.

Nun die Frage wie eine saubere Fehlerbehandlung aussehen muss. Gibts dazu ein Buch oder Text bzw. was ist die gängige Vorgehensweise?

Hallo schaffner,

es sollte klar sein, dass Fehlercodes out sind. Das normale sind Exceptions. Das sollten wir als gegeben annehmen. Wenn nicht, wäre wir bei [Hinweis] Wie poste ich richtig? Punkt 1.1.1.

Außerdem sollte klar sein, dass Exceptions nur für Ausnahmen gedacht sind, also Abweichungen von normalen oder besser gesagt erwarteten Programmablauf.

Von der Verwendung von Exceptions gibt es eigentlich nur eine Ausnahme, nämlich die TryAbc (z.B. TryParse) Methoden, immer dann, wenn es für den Benutzer zu aufwändig wäre, selbst eine Prüfung (der Parameter) zu implementieren, die verhindert, dass eine Exception auftritt.

Wo die Exceptions geworfen werden ist auch klar. Da wo die Ausnahmesituation bemerkt wird.

Bleibt eigentlich nur die Frage, wo Exceptions behandelt werden. Und das ist letztlich auch nicht schwierig. Immer da, wo man sie behandeln kann. Wo nicht, lässt man sie einfach weiter nach oben wandern. EDIT: Spätestens ganz oben sollte man die dann aber doch irgendwie behandeln, denn wenn man es nicht tut, stürzt die Anwendung mit einer unbehandelten Ausnahme ab.

herbivore

Danke.

Hallo Kollegen,

was ich an der Stelle noch zu bedenken geben möchte, ist, dass man auch einen Weg schaffen sollte, wie die Informationen über einen Fehler vom Kunden / Benutzer zum Entwickler gelangen können. An der Stelle kann es unterschiedlichste Wege geben.

Ich persönlich setze an der Stelle gerne auf Protokollierung zu (fast) allen Exception / wichtigen Ereignissen und auf aut. generiert Fehlerberichte, falls eine unbehandelte Ausnahme auftritt. Für beides gibt es allerdings keinen wirklichen Standard im .Net. Zumindest keinen, der mir bekannt wäre.

Gruß
Roland

Für beides gibt es allerdings keinen wirklichen Standard im .Net. Zumindest keinen, der mir bekannt wäre.

Es gibt ja auch viele Möglichkeiten wie man sowas protokollieren kann. Der eine hat eine DB zur Verfügung wo mans reinschreiben kann, dann bietet sich das natürlich an. Der andere darf nicht mal ins Dateisystem schreiben.
Dann gibts Internetzugang über den man Mails schicken kann, oder halt nicht.
Da schaut man am besten was möglich wäre und nutzt die Chancen die man hat. Ereignisprotokoll von Windows wäre auch noch da, aber wie man da regelmäßig nach Fehlern sucht möchte ich keinem User erklären müssen.

Hallo schaffner,

Gibts dazu ein Buch oder Text bzw. was ist die gängige Vorgehensweise?

Tja, die Fehlerbehandlung ist nicht so einfach. Aber ein Buch gibt es darüber bestimmt nicht, da hilft eigentlich nur Erfahrung sammeln. Im Prinzip sollte man darauf achten, daß alle Benutzereingaben soweit wie möglich validiert werden, um dann an dieser Stelle darauf reagieren zu können.

Alle anderen Exceptions, die dein Programmcode so produziert, sollten möglichst an zentraler Stelle abgefangen werden, denn darauf kann der Benutzer dann nicht mehr anders reagieren, als OK zu klicken, oder einen automatisch erstellten Fehlerbericht zu senden.

Andererseits ist es während der Entwicklung wichtig, daß diese Exceptions dort geworfen werden, wo sie auftreten. Denn in diesem Fall ist es ja wirklich ein fehlerhafter Programmzustand, dem man auf die Spur kommen will.

Bei der Auslieferung des Programmes gemäß dem Bananenprinzip kann man aber trotzdem nicht ausschließen, daß solche Exceptions entstehen, deshalb muß man sie abfangen, damit das Programm nicht beendet wird und man einen Fehlerbericht senden kann.

Um beides zu ermöglichen, verwende ich meistens diesen oder einen ähnlichen Konstrukt:

#if !DEBUG
			AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(OnUnhandledException);
#endif

In der OnUnhandledException-Methode wird dann ein Fehlerbericht erzeugt oder einfach eine Fehlermeldung angezeigt. Beim Debuggen hat man die Exceptions dann aber immernoch an der Stelle, wo sie geworfen werden.

Christian

Hallo

Im Prinzip sollte man darauf achten, daß alle Benutzereingaben soweit wie möglich validiert werden, um dann an dieser Stelle darauf reagieren zu können.

Und wenn die Eingabe nicht i.O ist, muss man das doch dem Benutzer melden, also muss ja wieder eine Exception ausgelöst werden.

In der Datenschicht kannst man ja nicht einfach MessageBox("Da ist ein Fehler!").Show() anzeigen.
Die Information muss doch mit throw new Exception() weitergegeben werden? Oder?

Gruss Lothi

Hallo Lothi,

die Validierung von Benutzereingaben sollte schon ohne Exceptions erfolgen. Natürlich hast du recht, dass in der Datens(ch)icht (ich nenns mal Business-Layer) auf keinen Fall mit dem Benutzer interagiert werden sollte. Aber das bedeutet nicht, dass man eine Exception werfen muss, weil die Validierung zu Teil sowieso im GUI erfolgt (z.B. ob sich ein String in eine Integer-Zahl umwandeln lässt) oder der Business-Layer entsprechende Prüfmethoden (z.B. TryAbc) zur Verfügung stellt. Fehleingaben des Benutzers sind ja keine Ausnahmesituationen, sondern treten regelmäßig auf. Schon deshalb ist das kein Fall für Exceptions.

In [Artikel] Attribute zur Prüfung von Properties verwenden beschreibe ich ein System, das es dem GUI ermöglicht, die Business-Objekte zu fragen, welche Prüfungen erforderlich sind und die Prüfungen selbst vorzunehmen. Exceptions werden nur geworfen, wenn sich das GUI das ignoriert und versucht ungeprüfte, fehlerhafte Werte zu setzen.

herbivore

Hi Lothi,

mit Validierung der Benutzereingaben meine ich nicht das Werfen von Exceptions, sondern das Abfangen und Auswerten. Einfaches Beispiel: Der Benutzer soll eine Zahl eingeben, und er gibt Buchstaben ein. Double.Parse wirft eine Exception, die muß in eine verständliche Fehlermeldung übersetzt werden, damit der Benutzer seine Eingabe wiederholen kann.

Christian

Dazu nimmt man besser
if (double.TryParse(...))
und gibt dann gleich eine eigens erstellte Meldung aus.

Für die Validierung von Buissnesobjekte verwenden wir bevorzugt die Enterpriselib, kann ich nur empfehlen. Exceptions wären dafür echt zu teuer ..

Vielleicht sollte man mal den COntext eingrenzen denn "Fehlerbehandlung" finde ich nicht konkret genug.

grüße

Fehler wie nicht vorhandene Dateien (Konfigurationen oder so), oder etwas das eigentlich funktionieren sollte, kann man schon eine Exception werfen lassen.
Benutzereingaben gehören eher nicht dazu, denn man gibt schnell mal was falsch ein.

Hi chilic,

für mich ist die Angabe einer Datei oder einer URL eine Benutzereingabe, selbst wenn der Pfad dafür wiederum aus einer Datei kommt. Der Benutzer wählt also eine Datei aus, und muß zeitnah einen Hinweis bekommen, wenn die Daten nicht verarbeitet werden können. Das meine ich mit Validierung.

Christian

für mich ist die Angabe einer Datei (...) eine Benutzereingabe, (...)

Das sehe ich ähnlich. Die Frage, ob die Datei auch tatsächlich existiert (also der gesamte Pfad), ist für mich aber Bestandteil der Validierung. Wenn mir dann aber beim Zugriff auf diese Datei das Betriebssystem ein access denied um die Ohren schmeißt, dann ist das ein Fehler (der auch den Einsatz von throw Exception rechtfertigt).

Hinrich