Debug.Assert() - eher ein Kommentar


Thomas Wölfer
Thomas Wölfer

24. Juli 2007


Nimmt ein eher Debug.Assert() oder eher "throw new XXXException()" - offenbar eine Frage über die sich häufig zu wenig Gedanken gemacht wird.

Die Kurzanleitung lautet: Debug.Assert() nimmt man besser nie.

Etwas mehr Hintergrund:
Letztlich dient sowohl das werfen einer Exception als auch Debug.Assert() der Fehlersuche. Beim Assert() stellt man sicher, das eine bestimmte Bedingung vorliegt, was allerdings nur in Debug-Builds (also nicht beim Anwender der Software) passiert. Wirft man eine Exception, so verhält sich die Sache anders: Der Test der Bedingung findet vor dem werfen der Exception statt - und beides passiert sowohl in Debug- als auch in Release-Builds.

Man muss sich die Frage stellen: Was will man eigentlich erreichen, wenn eine Fehlerbedingung eintritt. Und die Antwort ist da relativ einfach: Mal will, das das Programm abstürzt - und zwar so schnell wie möglich (und wenn irgend möglich, auch mit einer passenden Fehlermeldung - am besten mit einer, die man auch noch gleich auf einen eigenen Mail- oder Webserver transportieren kann.).

Mit "so schnell wie möglich" ist gemeint, das das Programm möglichst nicht mit einem fehlerhaften Zustand weiterbetrieben werden sollte, denn das führt nur dazu, das Folgefehler auftreten: Die machen es aber schwieriger, das eigentliche Problem zu diagnostizieren. Behandelt man aber Fehler mit Debug.Assert(), und tritt der Fehler dann beim Anwender - also in einem Release-Build - auf, dann läuft das Programm einfach ganz "normal" weiter - nur eben in einem Zustand, für das es nicht gedacht war. Dieser Zustand für dann dazu, das es zu einem späteren Zeitpunkt und an einer ganz anderen Stelle ganz sicher zu einem Absturz kommt - und zwar zu einem, dessen Ursache nicht mehr zu erklären ist: Ein Zustand, der bei der verwendung einer Exception statt eines Assert()s erst gar nicht eintreten würde.

In den allermeisten Fällen reicht es schon aus, einfach nur die eingehenden Parameter einer Funktion zu prüfen - und das dürfte praktisch nie ein Performance-Problem machen. (In den seltenen Fällen wo das vielleicht doch mal der Fall ist, nimmt man halt eben doch mal Debug.Assert()). Passt ein Parameter nicht, wirft man eine Exception.

Ein Debug.Assert() ist bestenfalls eine Art sehr deutlicher Kommentar, aber kein sinnvoller Mechanismus für die Qualitätssicherung.