Verwenden Sie Ausnahmen für außergewöhnliche Dinge, Dinge, von denen Sie nicht erwarten können, dass sie zu oft auftreten. Dinge, die darauf hinweisen, dass etwas schief geht. Wenn beispielsweise das Netzwerk ausfällt, ist dies eine Ausnahme für einen Webserver. Wenn die Datenbank nicht verfügbar ist, bedeutet dies, dass etwas nicht stimmt. Wenn die Konfigurationsdatei fehlt, bedeutet dies wahrscheinlich, dass der Benutzer damit einen Fehler gemacht hat.
Verwenden Sie keine Ausnahmen, um mit falschem Code umzugehen. Um die Richtigkeit des Codes zu überprüfen, sollten Sie entweder die Zusicherungen oder in .NET Framework 4 und höher Codeverträge verwenden (die Zusicherungen ersetzen und zusätzliche, besonders nützliche Funktionen aufweisen).
Verwenden Sie Ausnahmen nicht in Ausnahmefällen. Die Tatsache, dass der Benutzer, wenn er aufgefordert wird, eine Nummer einzugeben, "Hund" eingibt, ist keine Ausnahme, die eine Ausnahme verdient.
Seien Sie vorsichtig bei der Auswahl der Ausnahmetypen. Erstellen Sie bei Bedarf Ihre eigenen Typen. Wählen Sie die Erbschaft sorgfältig aus und denken Sie daran, dass das Fangen von Eltern auch die Kinder fängt. Niemals throw Exception.
Verwenden Sie keine Rückkehrcodes für Fehler. Fehlercodes können leicht ausgeblendet, ignoriert und vergessen werden. Wenn ein Fehler auftritt, können Sie ihn entweder behandeln oder an den oberen Stapel weitergeben.
In Fällen, in denen erwartet wird, dass eine Methode einen Fehler zurückgibt und der Fehler nicht außergewöhnlich ist, verwenden Sie Aufzählungen, niemals Fehlernummern. Beispiel:
// Note that the operation fails pretty often, since it deals with the servers which are
// frequently unavailable, and the ones which send garbage instead of the actual data.
private LoadOperationResult LoadProductsFromWeb()
{
...
}
Die Bedeutung von LoadOperationResult.ServerUnavailable, LoadOperationResult.ParsingErrorusw. ist viel deutlicher, als sich beispielsweise daran zu erinnern, dass Code 12 bedeutet, dass der Server heruntergefahren ist, und Code 13 - dass die Daten nicht analysiert werden können.
Verwenden Sie Fehlercodes, wenn sie auf die allgemeinen Codes verweisen, die jedem Entwickler in der jeweiligen Domäne bekannt sind. Erfinden Sie beispielsweise keinen Enum-Wert für HTTP 404 Not Found oder HTTP 500 Internal Server Error neu.
Hüten Sie sich vor Booleschen. Früher oder später möchten Sie nicht nur wissen, ob eine bestimmte Methode erfolgreich war oder nicht, sondern warum. Ausnahmen und Aufzählungen sind dafür viel mächtiger.
Fangen Sie nicht jede Ausnahme ab (es sei denn, Sie befinden sich ganz oben auf dem Stapel). Wenn Sie eine Ausnahme abfangen, sollten Sie bereit sein, damit umzugehen. Das Abfangen von allem zeigt, dass es Ihnen egal ist, ob Ihr Code korrekt ausgeführt wird. Dies löst möglicherweise das Problem "Ich möchte jetzt nicht nach Lösungen suchen", kann Sie aber früher oder später verletzen.
Werfen Sie in C # niemals Ausnahmen wie die folgenden erneut aus:
catch (SomeException ex)
{
...
throw ex;
}
weil Sie den Stapel brechen. Tun Sie dies stattdessen:
catch (SomeException)
{
...
throw;
}
Bemühen Sie sich, wenn Sie Ausnahmemeldungen schreiben. Wie oft habe ich sowas schon gesehen throw Exception("wrong data")oder throw Exception("shouldn't call this method in this context"). Andere Entwickler, darunter Sie sechs Monate später, hätten keine Ahnung, welche Daten falsch sind und warum oder warum wir eine Methode nicht in einem Kontext oder in welchem Kontext genau aufrufen sollten.
Dem Benutzer keine Ausnahmemeldungen anzeigen. Sie sind für normale Leute nicht zu erwarten und für Entwickler selbst oft sogar unlesbar.
Lokalisieren Sie keine Ausnahmemeldungen. Das Durchsuchen der Dokumentation nach einer lokalisierten Nachricht ist anstrengend und sinnlos: Jede Nachricht sollte nur in Englisch und Englisch verfasst sein.
Konzentrieren Sie sich nicht ausschließlich auf Ausnahmen und Fehler: Protokolle sind ebenfalls äußerst wichtig.
Vergessen Sie in .NET nicht, Ausnahmen in die XML-Dokumentation der Methode aufzunehmen:
/// <exception cref="MyException">Description of the exception</exception>
Das Einbeziehen von Ausnahmen in die XML-Dokumentation erleichtert die Arbeit der Person, die die Bibliothek verwendet, erheblich. Es gibt nichts Ärgerlicheres, als zu erraten, welche Ausnahme möglicherweise von einer Methode ausgelöst werden könnte und warum.
In diesem Sinne¹ bietet die Java-Ausnahmebehandlung einen strengeren und besseren Ansatz. Es zwingt Sie, entweder mit Ausnahmen umzugehen, die möglicherweise von den aufgerufenen Methoden ausgelöst werden, oder in Ihrer eigenen Methode zu deklarieren, dass die Ausnahmen ausgelöst werden können, die Sie nicht behandeln, wodurch die Dinge besonders transparent werden.