Faules Programmierervolk

on

Programmierer sind faul!

Genau deshalb sind sie Programmierer geworden. Oder eben Softwareentwickler. Oder eben ein Beruf, der impliziert, dass man was cooles mit Computern macht.

Und weil Programmierer so faul sind, benutzen sie gern mal Zeug das eh schon da ist. Und damit ist ausnahmsweise mal nicht redundanter Copy&Paste-Code.

Nein, ich rede viel mehr von Frameworks.

Da hat sich einer, oder eben viele, schon über eine zeitlang Gedanken gemacht, wie man ein Problem möglichst effizient und komfortabel in den Griff bekommt. Da freut sich der Programmierer und bedient sich fröhlich und beteiligt sich vielleicht sogar noch mit Optimierungen und Verbesserungsvorschlägen am Entwicklungsprozess.

Manchmal erwischt man aber einfach eine dumme Konstellation an Frameworks.

So wie ich diese Woche.

Dabei war es gar nicht mal die Kombination von mehreren Frameworks sondern eher die Tatsache, dass eines davon bei manchen Fehlern ziemlich nuschelt.Angefangen hat das ganze, wie schon gesagt, mit Bequemlichkeit. Der Bequemlichkeit dass ich ein XML-Schema nicht von Hand parsen, marshallen und unmarshallen wollte sondern, dass ich das ganze über JaxB mal eben schnell in eine paar schicke Java-Klassen umgewandelt habe.

Denn schon hier wurde die Bequemlichkeit von der Bequemlichkeit überrumpelt. In Form von Annotations. Das ist ein bisschen so das Steno in Java, das aber dafür sorgt, dass man ein bisschen weniger Code schreiben muss.

Dumm, dass man z.B. noch von Hand angeben muss, was denn im XML-Schema das Root-Element ist.

An dieser Stelle verlassen wir JaxB und wenden uns meinem speziellen Freund, dem Spring-Framework, zu.

Ich mag es! Es kann Dependencie-Injection, kommt gut mit Datenbankzugriffen klar und hat schicke Endpoints für Payload und WebServices. Und, man kann JaxB super darin integrieren. Einfach so.

Toll Sache.

Zumindest so lange bis man irgendwann mal von Spring mit folgender Fehlermeldung informiert wird:

IllegalStateException
Response already sent!

Schön, aber mein Client weiß davon noch gar nix. Zumindest ist dort, außer der Fehlermeldung, nichts angekommen.

Und so sitzt man dann da und lernt die drei Stufen des Programmiererzorns kennen.

Die erste Stufe ist ein mürrisches Zähneknirschen weil’s nicht auf Anhieb geklappt hat. Kein Programmierer wird gern an sein Fehlbarkeit erinnert.

Die zweite Stufe, die sich meist nach mehreren Versuchen und anhaltender Fehlermeldung einstellt, ist leichter Zorn, mittellautes Fluchen und Verwünschungen.

Die dritte Stufe stellt sich dann automatisch nach etwa einer Stunde ein. Es ist der Moment in dem man dem Rechner vor einem echte Gewalt antun will. Oder eben jemand der gerader zur Tür reinkommt.

Ich bin heute wirklich bis Stufe drei gekommen.

Wegen eben jener Fehlermeldung oben, die ungefähr so viel aussagt wie:

Tja, du hast was falsch gemacht! Jetzt such! Ich helf dir nicht. Egal wie viele Try-Catch-Blöcke du machst und wie feingranular du den Logger einstellst. Ich werde es dir nicht verraten!

Ja, man wurschtelt sich so langsam durch die üblichen Taktiken. Die alte Version geht, die Neue nicht. Also muss es was mit den JaxB-Dateien zu tun haben, aber da habe ich eigentlich auch nichts gemacht.

„Nichts gemacht“ war dann der Schlüssel. Ich kam irgendwann auf den Trichter, dass es vielleicht daran liegt, dass ich beim Auftreten des Fehlers den Namespace der Schemadateien im XML gewechselt habe.

Jaha! Das war es… Wie schon gesagt: Faul! Ich habe nicht alle generierten Klassen verglichen und dabei übersehen, dass man scheinbar bei einem Namespacewechsel wieder neu das Root-Element definieren muss.

Hätte Spring ja auch mal anders ausdrücken können. Sowas wie „Ich kann das XML nicht aufbauen“ statt mich die drei Stufen des Zorns durchwandern zu lassen.

Aber das wäre ja zu einfach gewesen 🙂