#include <assert.h>
int strlenChecked(char* s) {
  assert(s != NULL);
  return strlen(s);
}

Der Code oben ist ein Beispiel für die Benutzung von Assertions. Ich sehe da keine Vorteile gegenüber einer Exception. Wofür sind sie gut?

Eine Assert-Anweisung ist einfach eine bedingte Anweisung, die wahr sein sollte, gefolgt von Text, der ausgegeben wird, wenn dies nicht zutrifft.

Asserts sind Conditonal-Brakepoints im Code. Sie helfen dem Programmierer dabei wärend der Entwicklung darauf zu achten, das alles seinen richtigen gang geht. Wird eine Assert-Anweisung ausgelößt, hat man einen Fehler in seiner Programmlogik. Nicht aber zwingend auch im Programm selbst. Nehmen wir ein Beispiel eine Funktion die 2 werte dividiert.

public function double dividiere(double dividend, double divisor){
  Debug.Assert ( divisor != 0 , "Divisor ist 0!" );
  if( divisor != 0 ) return dividend / devisor;
  return 0;
}

Hier wird niemals eine Exeption geworfen, da die Division durch 0 behandelt wird. Jedoch möchte ich gern als Programmierer wissen, das eine Division durch 0 überhaupt "angefordert" wurde, da das garnicht passieren sollte. Da es nicht passieren sollte haben wir folgerichtig eine Fehler in unsere Programmlogik. Dafür nehme ich "Debug.Assert" was bewirkt, das der Debugger an dieser stelle anhällt, wenn der divisor 0 ist. Natürlich kann ich das auch mit Conditional-Brakepoints lösen jedoch sind die deutlich langsamer und in großen Projekten zu umständlich. Hin zu kommt das nicht in jeder Programmierumgebung Conditional-Brakepoints im Projekt-file gespeichert werden was Entwicklungen in Programmierteams erschweren würde, da jeder selbst die Brakepoints und ihren Bedingungen pflegen müßte. Als dritte alternative Lösung könnte man natürlich auch die Division duch 0 nicht behandeln und eine Exeption schmeißen. 1. ist dies jedoch nicht in jedem Fall gewünscht und zweitens kann man über eine Exeption nicht "drübersteigen". Über Asserts und Conditnal Brakepoints schon.

Mehr Details:

MSDN :: Assertionen in verwaltetem Code
Galileo Openbook C# :: Kapitel 33 Defensive Programmierung

Meine Antwort bezieht sich jetzt nur auf Java. Dort wird selbst von offiziellen davon abgeraten, assert zu benutzen, weil es sich über eine Compiler-Flag deaktivieren lässt und somit zur Laufzeit keine Sicherungen mehr bestehen!

Das Thema dazu heißt Design-by-contract oder DBC. Du hast für jede Methode Pre- und Postconditions sovie Invarianten, die zu jeder Zeit der Ausführung gelten. Am besten liest du mal unter diesem Thema nach.

Ich empfehle die Benutzung einer Check-Klasse. Die kannst du selber schreiben oder eine offizielle nehmen. Wichtig ist nur, dass sie funktioniert und auch benutzt wird. Ein Aufruf für dein Beispiel nach Java portiert könnte z.B. so aussehen:

int stringLengthChecked(String s) {
  Check.isNotNull(s);
  return s.length();
}

So wie ich das verstanden habe dienen asserts in Java nur dazu waehrend der Enwicklung eben kein Exception Handling betreiben zu muessen.

Genauso bei tests: die Ergebnisse werden ja von einem Entwickler interpretiert und dem reicht ein assert um zu sehen was schief laeuft (meistens ...)

Und was mir noch eingefallen ist: Soweit ich weiss wuerde die Runtime Environment mit default Einstellungen garnichts gegen ein "assert(5 != 5);" haben.
Man muss glaub ich einen parameter setzen um assertions zu aktivieren