Die Applikation. Unendliche Weiten. … *räusper*
So schlimm ist die Welt der Software-Entwicklung nun zwar auch nicht, dass man blindlinks irgendwo im Dunkeln rumdüst und völlig überraschend in einer Raumzeit-Anomalie hängt oder von Q für die Verbrechen der Menschheit angeklagt wird.
Aber gerade bei neuen Software-System hat man viele Stellen noch nicht berührt und muss sich häufig auf bereits existierendes Verhalten verlassen, wenn man neue Komponenten integriert. So geschehen heute. Ich möchte kurz vorstellen – die Aufgabe:
Rufe via REST eine URL auf, die den Status einer Entity umsetzt.
Zusätzliche Herausforderung:
Kann sein, dass die Gegenstelle nicht da ist.
Es folgte eine Odyssee von URL-Anpassungen. So mach ich mich daran, den Aufruf zu implementieren und bekomme ein einziges Wort zurück “StatusNotAllowedException“. Ich denk mir so: “Ok, das hört sich doch gut an.”, da ich wusste, dass die Status-Änderung mit dem aktuellen Objekt wirklich nicht erlaubt bzw. sein sollte. Witzigerweise war aber das Problem, dass ich einen völlig falschen Call getriggert hatte – klassisch Copy&Paste. Erst nachdem ich verkündete, dass der Aufruf implementiert sei, wurde ich aufgeklärt, dass die Antwort nicht korrekt ist. Nach kurzem scharfen Hinsehen war die URL dann auch schnell ausgetauscht.
Also ging es auf zu Runde 2. Wie bereits angesprochen gab es ja noch die Nebeninfo, dass evtl. die Empfängerstelle noch nicht implementiert ist. Darum gab es auch hier wieder für mich keinen wirklichen Argwohn als die Schnittstelle eine 404 zurücklieferte. Vorgewärmt von der ersten Fehlermeldung hab ich gleich gefragt, ob die Empfängerseite wirklich nicht da sei, worauf ein “doch, ist da” zurückgeliefert wurde.
Also schauen wir uns die URL an und entdecken: Oha, die Ports sind falsch. Aber nicht nur bei einer URL, sondern bei allen. Auch das geändert und somit kommen wir zu …
… Runde 3: Fehlermeldungen, die nicht da auftauchen wo sie erwartet werden. Leider gab es dann noch einen Schusselfehler bei der Änderung der Ports, so dass ein Aufruf an den alten Port geschickt wurde und mit unverhohlener Freundlichkeit meinte “kenn ich nicht”. In meinem Gesicht manifestierte sich die Frage “was kennst du nicht?”. In meinem Log tauchte nichts auf, im Log auf dem Server, auf dem wir dachten, dass der Aufruf aufschlagen sollte kam auch nichts. Zwar lag das eigentliche Problem am falschen Port, aber die Fehlermeldung sagte nichts darüber aus, was gerade schief gelaufen ist. Auch im Log des eigentlichen Servers – da wo der Call gelandet war – stand nichts aussagekräftiges. Am Ende half nur das 4-Augen-Prinzip um den Fehler zu finden.
Fazit: Ein Hoch auf die verbale Kommunikation und ein leidiges Buh auf schlecht formulierte Fehlermeldungen. Zwar muss man schon einiges an Schusseligkeit an den Tag legen um so viele Fehler hintereinander zu machen – und es passiert doch – aber gerade beim Ersten hätte es beinahe dazu geführt, dass ich mich in einer Sicherheit wähnte, die gar nicht da war und die uns im Produktiv-System ggf. teuer hätte zu stehen kommen können. Darum sollten Fehlermeldungen stets so viel Informationen enthalten, dass sie das eigentliche Problem konkret darstellen und entweder mögliche Ursachen oder mögliche Lösungen vorschlagen.