1. “70 percent of the world’s active business applications are written in COBOL”
Das scheint mir der Ursprung allen Übels zu sein. Dieses Gerücht kann auf eine Untersuchung der Gartner Group zurück geführt werden. Und das nicht gestern sondern im Jahre 2000. Was ein deutliches Zeichen für die Aktualität dieser Behauptung ist. Der Käse wurde vor über 10 Jahren mal gesagt und dann im Internet in die Zukunft gewatscht. Die 70% wurden im Jahre 2000 übrigens an den “lines of code” festgemacht. Was auch hirnrissig ist und womit wir beim nächsten Punkt sind.

2. lines of code
Die Einsatzhäufigkeit einer Programmiersprache wird hin und wieder anhand der aktuell weltweit produktiv laufenden lines of code gemessen. Auch das ist wieder totaler Quatsch. Und natürlich liegt COBOL da richtig weit vorne. Eine nicht-objektorientierte Programmiersprache die fast ausschließlich nur aus dem Befehl MOVE besteht, braucht schon mal ein paar tausend Zeilen um die Fibonacci-Zahlen auszugeben. Das COBOL mit seinen Billionen von produktiven Source-Zeilen beim Zählen der Zeilen einen Blumentopf gewinnt, scheint mir wenig verwunderlich. Es ist jedoch nicht immer so, dass der der viel tut viel Sinnvolles tut.

3. TIOBE Index
Im TIOBE programming community index hat COBOL sich inzwischen auf Platz 41 runter gekämpft. Dieser Index ist eine sortierte Liste der Programmiersprachen und wird aus der Frequenz der Suchanfragen mit dem Namen der Programmiersprache als Keyword zusammen gesetzt. Dafür werden zahlreiche große Suchmaschinen verwendet. Man kann das Ergebnis als eine Liste der Aktivität der Programmiersprachen werten. Und COBOL erreicht dabei gerade mal 0,331 %. Da auch produktiv laufende Anwendungen ein gewisses Volumen an Wartung benötigen und dabei ein Entwickler zur Arbeit geknechtet wird, scheint es auch hier wieder so als sei kaum eine produktive Anwendung in COBOL geschrieben, denn schließlich benutzt heute jeder eine Suchmaschine.

Butter bei die Fische:

TOTALER UNFUG!

COBOL, ist weiter weg von produktiv, als mindestens 40 andere Programmiersprachen auf der Welt. Und wenn es noch Unternehmen gibt, die COBOL produktiv einsetzen ohne einen Gedanken an eine Neuentwicklung ihrer Applikationen zu verschwenden, dann sind diese Unternehmen schon pleite und wissen es noch nicht und in meinen Augen maximal bemitleidenswert.

So… Tacheles Ende…

1
2
3

if (BEDINGUNG) {
    throw new Exception("An error occurred.");
}

oder

1
2
3
4
5

try {
    // some code
} catch (Exception e) {
    // exception handling
}

Diese Art mit der java.lang.Exception herumzuspringen birgt einige Nachteile und sogar Risiken. Warum Nachteile enstehen und welchen Risiken man sich aussetzt wenn man sein Exception Handling an der Basisklasse aller Exceptions ausrichtet, sei hier deshalb kurz aufgezeigt:

Lesbarkeit

Die Lesbarkeit des Codes leidet unter dem Werfen von java.lang.Exception.

1

throw new CorruptFileException();

sagt deutlich mehr aus als ein einfaches

1

throw new Exception();

Ich selbst vergleiche das Werfen von java.lang.Exception gerne damit jemandem versehentlich auf den Fuss zu treten. Das ist ungefähr so, als träte man jemanden versehentlich auf den Fuss und bekommt als Antwort einen Schlag ins Gesicht. Es geht einfach ein großer Teil der Information der Exception verloren.

Angst und Unsicherheit

Bei catch-Blöcken, die java.lang.Exception fangen, wird mir immer mulmig im Bauch. Es entsteht der Eindruck als wüsste der Entwickler nicht, welche Fehler in diesem Teil seiner Software auftreten können.

1
2
3
4
5

try {
    // some code
} catch (Exception e) {
    // exception handling
}

Um diese Unsicherheit zu beseitigen, wird fälschlicherweise oft auf java.lang.Exception gecatcht. Das ist schlecht. Besser ist es die Exception einfach “nach oben” durchkrachen zu lassen oder nur die Exceptions zu fangen, die der zugehörige Source-Code auch werfen kann. Ein catch auf java.lang.Exception ist im Zweifelsfall immer die schlechteste Wahl, da hier auch alle Exceptions gefangen werden, die an dieser Stelle des Source-Code besser nicht gefangen werden sollten. Noch schlimmer wird es wenn auf Throwable gecatcht wird.

1
2
3
4
5

try {
    // some code
} catch (Throwable t) {
    // exception handling
}

An dieser Stelle werden nicht nur alle Exceptions sondern auch alle Errors gefangen. Das hat dann mit Genauigkeit gar nichts mehr zu tun.

Schlechtere Wartbarkeit

Ein Entwickler, der für diese Software später vielleicht mal die Pflege und/oder Änderungen übernimmt und mit der Software nicht vertraut ist, der wird sich unter Umständen tot suchen, wenn das Logging nicht Klasse und Zeile des Sources mitloggt und einen catch wie in dem folgenden Beispiel macht.

1
2
3
4

try {
} catch (Exception e) {
    LOG.error(e);
}

Dieser Fehler kann insbesondere dann kritisch werden, wenn eine Software das für das Logging das Log4J PatternLayout verwendet, das gerade beim Loggen von Klasse und Zeile sehr viel Performance frisst und deshalb für das Logfile manchmal maximal noch Datum, Uhrzeit und Log-Level ins Pattern konfiguriert wird.

Verlust des Informationsgehalts

Nicht nur die Message einer Exception sondern auch der Name einer Exception kann auch einen Informationsgehalt haben und den Code leserlicher machen. So ist

1
2
3
4
5

try {
    // some code
} catch (PrinterUnreachableException e) {
    // exception handling
}

mit deutlich mehr Information bestückt als

1
2
3
4
5

try {
    // some code
} catch (Exception e) {
    // exception handling
}

RuntimeExceptions werden verschluckt

Entwickler sind auch nur Menschen und Menschen passieren Fehler. Jeder Entwickler hat schon mal einen Fehler gemacht, der zum Beispiel eine NullPointerException oder eine ähnliche RuntimeException ausgelöst hat.

1
2
3
4
5
6
7

try {
    // some code
    Person person = null;
    String = person.getName();
} catch (Exception e) {
    LOG.error("An error occurred.");
}

Diese NullPointerException wird einfach verschlammt. Sie weißt auf einen Programmierfehler hin aber verschwindet weil sie unsachgemäß verschlammt wird. Der Entwickler, der diesen Source nun debuggen soll, hat keinen sinnvollen Anhaltspunkt was schief gelaufen sein könnte.

Erst fangen und dann doch lieber weiter werfen

1
2
3
4
5
6
7
8

public void foo() throws Exception {
    try {
        // some code
    } catch (Exception e) {
        LOG.error(e);
        throw e;
    }
}

Dieser Fall ist auch mit einem negativen Beigeschmack versehen. Auch wenn er auf den ersten Blick vielleicht völlig korrekt erscheinen mag. Die gefangene Exception wird ins Logfile geschrieben und dann weitergeworfen. Was wird wohl der Source außerhalb Methode foo machen? Richtig! Er wird die Exception irgendwo erneut fangen und mit großer Wahrscheinlichkeit noch mal im Logfile versenken. Die Exception wird 2 Mal im Logfile versenkt obwohl sie nur ein mal aufgetreten ist. Ugly hoch drei!

Vertuschen

Leere catch-Blöcke sind genauso gefährlich wie das Fangen von java.lang.Exception. Doch noch viel schlimmer wird das Ganze, wenn eine java.lang.Exception gefangen wird und dann zusätzlich auch noch der catch-Block leer bleibt.

1
2
3

try {
    // some code
} catch (Exception e) {}

Dieser Fall ist der Supergau. Der Fehler wird weder behandelt noch wird er jemals auffindbar. Er wird vertuscht und “das große Suchen” beginnt. Eine weitere Form des Vertuschens ist das Loggen der Exception-Message innerhalb catch-Blocks auf java.lang.Exception.

1
2
3
4
5

try {
    // some code
} catch (Exception e) {
    LOG.error(e.getMessage());
}

Diese Art der Vertuschung wird manchmal damit begründet, dass das Logfile nicht zu lang werden soll und/oder der Logfile Inhalt nicht mehr schön aussieht. Wobei wir dann natürlich bei der Frage wären, ob wir das Logfile überhaupt noch brauchen. Ein Logfile das “hübsch” aussieht, das ist genauso hilfreich bei einer eventuellen Fehlersuche als wenn man die Software ohne Logfile im Blindflug betreibt. Noch eine weitere Form des Vertuschens ist das einfache returnen von null im Fehlerfall.

1
2
3
4
5

try {
    // some code
} catch (Exception e) {
    return null;
}

Diese Möglichkeit kann zwar in einigen Fällen sinnvoll erscheinen aber weißt auf alles andere als einen guten Entwicklungstil hin. Und gerade bei umfangreicheren Methoden ist die Lösung pauschal schon falsch.

Wie man jetzt sicher einfach versteht, ist das direkte arbeiten mit java.lang.Exception eher so der “Holzfäller-Style” der Programmierung. Deshalb sollte man sich neben “Fail fast! Fail early! Fail loud!” auch mit den für den jeweiligen Source-Bereich passenden Exceptions arbeiten.

In diesem Sinne…
Lasst es krachen! Aber richtig!

Für weiter Interessierte empfehle ich:
http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html

Vielen Dank und viel Spaß…

Phil

http://united-coders.com/phillip-steffensen/maven-2-part-1-setting-up-a-simple-apache-maven-2-project

1234567890
(Unixtimestamp)

Seit dem 01.01.1970 sind genau 1234567890 Sekunden vergangen. Das ist ein Grund zum feiern, weil dieser Termin einmalig ist. Diesen Termin gibt es nur ein einziges Mal. Heilig Abend, Sylvester und Ostern gibt es jedes Jahr. Das sind so die Mainstream-Chicks unter den Feiertagen. Also eher uninteressant. Deshalb sollte man heute Mal so richtig die Sau raus lassen. Von diesem Tag dürfen wir unseren Kindern und Kindeskindern noch erzählen.

Django rawks!
(bedeutet so viel wie: Django rocks! xD)

Das Django Web Framework wirklich nice. Eine Web Applikation ist innerhalb weniger Minuten aus dem Boden gestampft. Ich muss mich nicht mehr um die Datenbank kümmern. Das tut Django nun für mich. Ich muss mir für meine Web Applikationen kein Admin-Frontend mehr basteln. Das tut Django nun für mich. Eleganz hat einen neuen Namen: Django. Ich bleibe dran… Meine nächste Webapp werde ich definitiv mit Django bauen.

HTTP Status 403 – Access to the requested resource has been denied

Woran liegt das!?

Ganz einfach: Das ist ein Sicherheits-Aspekt. Der Nutzer des Tomcats soll die Konfiguration selbst vornehmen, damit der Tomcat produktiv niemals mit einem Default-Manager-User eingesetzt wird. Die Datei tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) sieht per Default wie folgt aus:

1
2
3
4
5
6
7
8
9

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
</tomcat-users>

Man erkennt auf den ersten Blick: Da gibt es ja gar keinen Manager-User. Aha!

Aber was ist zu tun, wenn man nun doch die Manager-Applikation nutzen möchte!?

Auch das ist wieder denkbar einfach. Man fügt einfach einen neuen Tomcat-User mit einer Manager-Rolle ein. Dazu muss die tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) wie folgt angepasst werden:

1
2
3
4
5
6
7
8
9
10
11

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="manager" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
    <user username="manager" password="manager" roles="manager,admin" />
</tomcat-users>

Danach muss der Tomcat neu gestartet werden, so dass die Einstellungen übernommen werden können. Jetzt kann man sich mit dem User “manager” und dem Passwort “manager” bequem ins Manager-Servlet einloggen.

Wichtig!

Bevor der Tomcat produktiv eingesetzt wird, sollte diese Änderung jedoch abgewandelt oder rückgängig gemacht werden, da sonst von außen auf das Manager-Servlet zugegriffen werden könnte und ganze Anwendungen undeployt (vom Server entfernt) werden können.

Warum schreibe ich das hier?

Ich habe diese Lösung schon mehrfach gegoogelt und muss irgendwie jedes Mal wieder nachschlagen. Und weil mich das so nervt, pumpe ich die Lösung jetzt in meinen Blog, dann weiß ich wo sie steht.