9.9    Assertions * 

Die Übersetzung des englischen Wortes assertion lässt vermuten, worum es geht: um Zusicherungen. Assertions formulieren Aussagen, die beim korrekten Ablauf des Codes immer wahr sein müssen. Ist eine Bedingung nicht erfüllt, folgt eine Ausnahme, die darauf hinweist, dass im Programm etwas falsch gelaufen sein muss. Der Einsatz von Assertions im Code fördert die Dokumentation für den gültigen Programmzustand. Wir unterscheiden:

• Precondition: Zustand, der vor einer Operation immer wahr sein muss

• Postcondition: Zustand, der nach einer Operation immer wahr sein muss

Die Formulierung korrekter Zustände ist ein wesentliches Element von Design by Contract, einer Entwicklungsmethode, bei der es darum geht, einen »Vertrag« (engl. contract) aufzustellen über das, was ein Programm leisten muss. Bertrand Meyer, auch Erfinder der Programmiersprache Eiffel, prägte diesen Begriff.

 

9.9.1    Assertions in eigenen Programmen nutzen 

Java-Programme nutzen für Assertions im Quellcode die assert-Anweisung. Es gibt zwei Varianten, eine mit und eine ohne Meldung:

assert AssertConditionExpression;

assert AssertConditionExpression : MessageExpression;

AssertConditionExpression steht für ein Prädikat, das zur Laufzeit ausgewertet wird. Der Ausdruck wird nicht automatisch geklammert, da er sich nicht wie ein Methodenaufruf liest.

 

9.9.2    Assertions aktivieren und Laufzeit-Errors 

Assertions stehen immer in der Klassendatei, da der Compiler sie immer in Bytecode abbildet. Jedoch werden Assertions zur Laufzeit standardmäßig nicht beachtet, da sie abgeschaltet sind. Somit entsteht kein Geschwindigkeitsverlust bei der Ausführung der Programme. Um Assertions zu aktivieren, muss die Laufzeitumgebung mit dem Schalter -ea (enable assertions) gestartet werden.

Sind Assertions aktiviert und wertet die JVM das Ergebnis der assert-Anweisungen zu true aus, führt die Laufzeitumgebung die Abarbeitung normal weiter. Ergibt die Auswertung false, wird das Programm mit einem java.lang.AssertionError beendet. Wir haben gesehen, dass es zwei Varianten gibt:

assert AssertConditionExpression;

assert AssertConditionExpression : MessageExpression;

Der optionale zweite Parameter, MessageExpression, ist ein Text, der beim Stack-Trace als Nachricht in der Fehlermeldung erscheint. Die in Java ausgelösten Ausnahmen sind vom Typ »Error« und nicht vom Typ »Exception« und sollten daher auch nicht aufgefangen werden, da eine nicht erfüllte Bedingung ein Programmierfehler ist.

assert counter-- == 0;

boolean assertEnabled = false;

assert assertEnabled = true;

if ( ! assertEnabled )

  throw new RuntimeException( "Assertions müssen aktiviert werden" );

Beispiel

Eine eigene statische Methode subAndSqrt(double, double) bildet die Differenz zweier Zahlen und zieht aus dem Ergebnis die Wurzel. Natürlich weiß jeder Entwickler, dass die Wurzel aus negativen Zahlen nicht erlaubt ist, aber dennoch ginge so etwas in Java durch, nur ist das Ergebnis ein NaN. Sollte irgendein Programmteil nun die Methode subAndSqrt(double, double) mit einem falschen Paar Zahlen aufrufen und das Ergebnis NaN sein, muss ein Assert-Error erfolgen, da es einen internen Programmfehler zu korrigieren gilt:

Listing 9.33     src/main/java/com/tutego/insel/assertion/AssertKeyword.java, Ausschnitt

public class AssertKeyword {



  public static double subAndSqrt( double a, double b ) {

    double result = Math.sqrt( a - b );



    assert ! Double.isNaN( result ) : "Berechnungsergebnis ist NaN!";



    return result;

  }



  public static void main( String[] args ) {

    System.out.println( "Sqrt(10-2)=" + subAndSqrt(10, 2) );

    System.out.println( "Sqrt(2-10)=" + subAndSqrt(2, 10) );

  }

}

Rufen wir das Programm mit dem Schalter -ea auf:

$ java -ea com.tutego.insel.assertion.AssertKeyword

Die Ausgabe ist dann:

Sqrt(10-2)=2.8284271247461903

Exception in thread "main" java.lang.AssertionError: Berechnungsergebnis ist NaN!

  at com.tutego.insel.assertion.AssertKeyword.subAndSqrt(AssertKeyword.java:8)

  at com.tutego.insel.assertion.AssertKeyword.main(AssertKeyword.java:15)

 

9.9.3    Assertions feiner aktivieren oder deaktivieren 

Assertions müssen nicht global für das ganze Programm gesetzt werden, sondern können auch feiner deklariert werden, etwa für eine Klasse oder ein Paket. Mit geschickter Variation von –ea (Assertions aktivieren) und –da (Assertions deaktivieren) lässt sich sehr gut steuern, was die Laufzeitumgebung prüfen soll.

$ java -ea:com.tutego.App  ClassWithMain

$ java -ea:...  ClassWithMain

$ java -ea:com.tutego...  ClassWithMain

$ java -ea:com.tutego... -da:com.tutego.App  ClassWithMain