THE FINAL COUNTDOWN 2 – DIE FINALLY-CLAUSE IN JAVA

Es gibt leider ein wirklich ärgerliches Idiom/Pattern/Snippet, das man immer wieder in Java Code sieht:

SomeResult readSomething () {
    InputStream in = null;
    SomeResult result = null;
    try {
        in = new InputStream(....);
        // read from in in some way or other, 
        // build a result 
        result = new SomeResult(...);
    } catch (IOException e) {
        // log e in some way 
        result = null; 
    } finally {
        try {
            if (in != null) {
                in.close();
            }
        } catch (IOException e) {
            // (log e in some way) 
        }
    }
    return result;
} 

(Analog mit allen möglichen anderen Arten von Resourcen, OutputStream, Connection, ResultSet, Reader, Writer etc.)
Der obige Code ist noch nicht falsch per se, aber problematisch aus einer Reihe von Gründen:

• Der Code ist unnötig verbose
• Im Fehlerfall wird einfach null zurückgeben (i.d.R. wird bei solchem Code der Caller auch nicht auf null prüfen: hat ja beim Testen immer geklappt)
• Der Code ist anfällig im Falle von Änderungen und Erweiterungen
• Kein einziger Wert ist final

Richtig gefährlich wird es, wenn man noch eine zweite Resource hinzufügt, die geclosed werden muss, denn nur zu oft führt es zu Code wie diesem:

    InputStream in = null;
    // we just assume there is data from
    // a 2nd stream, but it could also be
    // a combination of ResultSets,
    // Connections, input and output streams...
    InputStream in2 = null;
    SomeResult result = null;
    try {
        in = new InputStream(....);
        in2 = new InputStream(....);
        // read from streams in some way or other,
        // build a result
        result = new SomeResult(...);
    } catch (IOException e) {
        // (log e in some way)
        // DERP!
        result = null;
    } finally {
        try {
            if (in != null) {
                in.close();
            } 
            // notice what's wrong here?
            if (in2 != null) {
                in2.close();
            }
        } catch (IOException e) {
            //log e in some way
        }
    } 
    return result;
}

Wenn es ein Problem mit dem ersten Stream gibt, ist es sehr gut möglich, dass im Fehlerfall in.close() fehl schlägt. Nun wird in2 nicht mehr geschlossen und wir haben ein Resource-Leak.

Wird readSomething häufiger aufgerufen und das Problem besteht weiter, kann dies zum Crash der App und schlimmstenfalls zu einer Instabilität des gesamten Systems führen. Bei Netzwerkverbindungen kann es z.B. so dazu kommen, dass das System keine weiteren Netzwerkverbindungen mehr aufbauen kann, weil die maximale Anzahl an Verbindungen geöffnet ist und nicht sauber geschlossen wurde.

Nicht immer kann man sich darauf verlassen, dass ein Beenden/Crash der Applikation wirklich alle Resourcen freigibt – und selbst wenn: eine crashende App oder eine App die keine Sockets mehr öffnen kann ist in den meisten Fällen schlimm genug.

finally richtig eingesetzt

Ändert man den Code nur ein wenig ab, ist er nicht nur besser lesbar, es kann auch nichts mehr schief gehen:

SomeResult readSomething () throws IOException {
    final InputStream in = new InputStream(...);
    try {
        final InputStream in2 = new InputStream(...);
        try { //read from streams in some way or other, 
            // build & immediately return a result
            return new SomeResult(...);
        } finally {
            in2.close();
        }
    } finally {
        in.close();
    }
}

Wir erzeugen den InputStream sofort bei der Deklaration. Deshalb kann er nicht null sein, also entfallen die lästigen null-Checks beim schließen (und NullPointerExceptions, wenn man den Check weg lässt).

Schlägt das Erzeugen des Streams bei der Erzeugung fehl, gibt es nichts zu closen; (schlägt ein Konstruktor fehl, haben wir in Java nur null als Resultat, nicht ein „halb erzeugtes“ Objekt wie in C++), der finally-Block wird aber gar nicht erreicht, weil der zugehörige try-Block gar nicht erst betreten wird.

Jede Resource wird, falls sie geöffnet wird, in einem eigenen finally-Block garantiert geschlossen – es kommt also auch nicht zu Resource Leaks, alles wird sauber & korrekt freigegeben. Wir kümmern uns nicht ums Exception Handling. Der Caller muss entscheiden was passiert, wenn die Aktion schief geht. Der Code sorgt nur dafür, dass im Fehlerfall alle Resourcen sauber freigegeben werden.

Eine Alternative für den Fall, dass es einen sinnvollen default Wert gibt, folgt weiter unten. Wir geben das Resultat auch nicht erst am Ende der Funktion zurück. Wer returnen sofort, wenn wir unser Ergebnis haben. Die finally-Blocks werden trotzdem garantiert ausgeführt. Wir tun quasi im innersten Block so, als könnte nichts schiefgehen und es gäbe gar kein Resource-Handing und haben so wesentlich leichteren zu lesenden und schreibenden Code.

Ein wenig Whitespace-Ketzerei

Für den Spezialfall „Ressourcen mit finally freigeben“ kann man sogar so etwas ketzerisches machen wie nicht nach einem try einzurücken. Für diesen ganz speziellen Fall kann es die Lesbarkeit IMHO deutlich erhöhen:

SomeResult readSomething () throws IOException {
    //CREATE RESOURCES
    final InputStream in = new InputStream(...);
    try {
    final InputStream in2 = new InputStream(...);
    try { //read from streams in some way or other,
    // build a result
    return new SomeResult(...);
    // CLOSE RESOURCES
    } finally { 
        in2.close();
    }
    } finally {
        in.close();
    }
}