Code Contracts machen die Validierung leicht und sorgfältig

Wenn der Code kompiliert wird, schreibt das Code-Contracts-System (sofern aktiviert) den Code etwas um. Zuerst eine Ausnahme: Wird Contract.Requires() der Text für eine Fehlermeldung übergeben, dann löst das statt des standardmäßigen Verhaltens eine Exception unter Verwendung dieses Textes aus. Doch außer in diesem Spezialfall (und wenn bestimmte Exceptions ausgelöst werden, wie in der Dokumentation beschrieben) ruft der Rewriter bei einem fehlgeschlagenen Aufruf von Contract die Methode ReportFailure() auf. Keine Angst, diese Methode wird automatisch generiert.

Wer will, kann sie jedoch durch eine eigene überschreiben. Die standardmäßige Implementierung löst das Ereignis „RaiseContractFailedEvent“ aus. Falls es keinen Handler für dieses Ereignis gibt, wird die Methode TriggerFailure() aufgerufen (auch hier kann man seine eigene Implementierung bereitstellen), die die Anwendung abbricht und die Ausführung an den Debugger übergibt. Das System löst also keine Exceptions aus (um Tester und Entwickler auf den Fehler aufmerksam zu machen), aber falls man diese Funktionalität bevorzugt, ist es trivial, sie bereitzustellen. Alternativ kann man die Laufzeitüberprüfung auch so modifizieren, dass stattdessen Fehler ausgelöst werden. Dafür muss ein entsprechendes Kästchen auf der Code-Contracts-Seite der Projekteigenschaften aktiviert sein.

Statische Analyse

Die statische Analyse von Code Contracts überprüft den Code, wenn er kompiliert wird, und hält nach problematischen Stellen Ausschau. Aus prinzipiellen Gründen kann eine statische Analyse natürlich nicht perfekt sein. Statt zu behaupten, dass der Code nicht funktioniert, meldet sie nur, dass ein Contract „nicht bewiesen“ ist. Die entsprechenden Warnungen erscheinen in der „Fehlerliste“ von Visual Studio.

Standardmäßig ist die statische Analyse deaktiviert, weil sie ein äußerst rechenintensiver Prozess ist, aber sie lässt sich auf der Eigenschaftenseite aktivieren. Weil die statische Analyse Unmengen von Warnungen erzeugen kann, die nicht unbedingt aussagekräftig sind, erlaubt einem das System, eine XML-Datei mit „Basis“-Fehlern zu definieren. Wenn diese „Basis“-Datei in die Analyse eingebunden ist, werden keine Warnungen über die Komponenten in dieser Datei ausgegeben. Das ist ein nützliches Feature, das es einem ermöglicht, sicherzustellen, dass nur neue, unbekannte Warnungen zu sehen sind.