Best Practices: Fehlerbehandlung

Jürgen Gutsch — Thu, 19 Aug 2010 08:42:00 GMT

In der Vergangenheit habe ich in vielen Projekten, vielen Anwendungen und auch hier im Forum immer wieder die gleichen Fehler bei der Fehlerbehandlung gesehen, was mich dazu veranlasst diesen Beitrag hier zu schreiben.

Im Grunde ist es immer folgender Fehler der beim Try&Catch gemacht wird:

try { [do some errors] } Catch (Exception ex) { log.Error(“Meine super duper Fehlermeldung”); throw ex; }

Das ist dann keine Fehlerbehandlung, sondern eher Fehler verstecken!

Oftmals wird dieses Konstrukt (“Fehlerbehandlung” mochte ich es nicht nennen) in jeder Methode genutzt die aufgerufen wird. Das hat dann den Effekt, dass dieses Konstrukt logisch wie folgt verschachtelt wird:

try { try { try { try { [do some errors] } Catch (Exception ex) { log.Error(“Meine erste super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine zweite super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine dritte super duper Fehlermeldung”); throw ex; } } Catch (Exception ex) { log.Error(“Meine vierte super duper Fehlermeldung”); throw ex; }

Oftmals wird wenigstens die aktuelle Exception dem Logger übergeben:

Catch (Exception ex) { log.Error(“Meine vierte super duper Fehlermeldung”, ex); throw ex; }

Aber auch das ist nur die halbe Miete.

Was soll da falsch sein ?

Schauen wir uns nochmal das erst Stück Code an. Angenommen es passiert ein Fehler und das Programm, springt in den Catch-Teil. Jetzt geht der Unsinn los:

Es wird eine Unsinnige Fehlermeldung ausgegeben!
Warum?
Falls die Meldung noch relevant sein sollte, enthält sie keine weiteren Informationen zu der eigentlichen Exception. Im Normalfall wurde der Code allerdings im Laufe der projektphase immer wieder geändert, was zur Folge hat, das die Nachricht längst nicht mehr stimmt oder es gibt inzwischen mehrere mögliche Fehlerquellen.
throw ex ist der nächste grobe Fehler: es wird zwar die selbe Exception noch einmal geworfen, mit der selben Fehlermeldung, allerdings wird der immens Wichtige StackTrace abgeschnitten (“breaking the stack”). Der StackTrace beginnt ab der Methode in der throw ex aufgerufen wird. Sollte der Fehler in einer aufgerufenen Komponente auftauchen, kann das nicht mehr ermittelt werden. Es wird immer so aussehen, als wäre der Fehler in der aktuelle Methode aufgetreten, und zwar genau dort, wo thro ex aufgerufen worden ist. Genauso wie der StackTrace geht auch die InnerEception verloren (Danke an Peter für den Hinweis.)
Selbst wenn die Exception an den Logger übergeben wird ist die Fehlerbehandlung unvollständig, denn es wird nur ein unvollständiger StackTrace gelogt.

Im Falle der verschachtelten Try&Catches sieht das so aus, dass 1. keine relevanten Fehlerinformationen geloggt werden und 2. jedes Mal der StackTrace bei jedem Catch von neuem beginnt.

Diese Fehlerbehandlung ist somit keine, sondern eine Selbsttäuschung.

Das wird man spätestens dann merken, wenn man als Entwickler vom Support die Meldung über einen Fehler bekommt und dann das Log-File analysieren muss. Ich wette das viele Fehler nicht per Log-File gefunden werden können.

Was ist zu tun?

Im ersten Schritt sollten alle throw ex Aufrufe durch ein einfaches throw ersetzt werden. Das führt dazu, dass die aufgetretene Exception genau so wie sie ist, nach “oben” weitergeleitet wird. Dann sollte das Logging angepasst werden: Bei einem einfachen Try&Catch sollte das Logging – wenn möglich – so geändert werden, dass die Exception an den Logger übergeben wird (Die meisten Logger sollten das Unterstützen):

try { [do some errors] } Catch (Exception ex) { log.Error(ex); throw; }

Im Fall der Verschachtelten Try&Catches wird nun noch an jeder Stelle in das Log geschrieben. Das ist nicht sinnvoll, das dadurch das Log sehr groß werden kann und die Informationen mehrfach im Log vorhanden sind. Es sollte also nur an einer Stelle geloggt werden und zwar am besten ganz oben, beim letzten Try&Catch.

In ASP.NET kann das sogar in der global.asax bei Application_Error gemacht werden.

Die verschachtelten TryCatches sehen dann logisch wie folgt aus:

try { try { try { try { [do some errors] } Catch (Exception ex) { throw; } } Catch (Exception ex) { throw; } } Catch (Exception ex) { throw; } } Catch (Exception ex) { log.Error(ex); HandleTheException(); }

Im letzten Catch wird dann die eigentliche Fehlerbehandlung gemacht: Es wird dem Benutzer eine sinnvolle Meldung ausgegeben (Nicht die Fehlermeldung, mit der kann der Benutzer nichts anfangen!)

Nach diesem Refactoring, sollte man sich fragen welche Try&Catches dann noch Sinn machen, wen nichts anderes Passiert, als die Exceptions durchzureichen. Ich bin ganz sicher, dass man einige nun Entfernen könnte.

Generell sollte man nicht grundlos alle möglichen Fehler abfangen, sondern in erster Linie Fehler vermeiden. Natürlich gibt es Stellen, bei denen man Fehler nicht Verhindern kann, das ist immer dann der Fall, wenn man aus seiner Anwendung raus auf etwas zugreift: Datenbank und Dateizugriffe, Web- und Webservice-Zugriffe, COM, etc.

Auf diese Art hat man nun schon mal eine relativ saubere Fehlerbehandlung.

Aber es geht immer noch besser:

An Stellen, an denen mögliche Fehler nicht verhindert werden können, können diese abgefangen und mit einer eigenen Exception nach “oben” weitergeben werden. Die ursprüngliche Exception wird dabei als InnerException mitgegeben:

Catch (Exception ex) { throw new MyVeryOwnHttpException(ex) }

So kann man in der Darstellungsschicht individuell auf die Fehler reagieren und dem Benutzer einen entsprechenden Hinweis geben:

Catch (MyVeryOwnHttpException ex) { log.Error(ex.InnerException); HandleTheVeryOwnHttpException(“Die Verbindung zum Server konnte nicht hergestellt werden.\n Bitte prüfen Sie ob Sie mit dem Internet Verbunden sind.\nUnd so weiter und so fort”, ex); }

Man kann so spezielle Arten von Ausnahmen zusammenfassen und entsprechend drauf reagieren. Es ist dem Anwender in der Regel egal, was der genaue Fehler ist. Ob das jetzt ein Verbindungsfehler ist oder der Server einen Fehler zurückgibt ist egal. Wichtig ist, dass in diesem Fall die Anwendung nicht mit dem Server kommunizieren kann.

In der Log-File steht auf jeden Fall der konkrete Fehler mit dem kompletten StackTrace und die Fehlersuche wird dadurch wesentlich vereinfacht.

Search results matching tags 'Architektur' and 'Exception Handling'

Best Practices: Fehlerbehandlung