© HappyAprilBoy/Shutterstock.com
Java Magazin
Exception Handling für APIs und Web-Apps mit Spring MVC

Ausnahmen sind die Regel

Ernstzunehmende Fehler im Programmablauf, fehlerhafte Benutzereingaben, der Aufruf eines ungültigen URL: Ausnahmen sind die Regel. Überdies können Exceptions durchaus ausdrucksvolle Stilmittel des Programmflusses sein. Sie sind Teil der Interaktion mit der Applikation und ein nicht zu unterschätzender der Teil der User Experience. Entscheidend ist der Umgang mit einer Exception und eine angemessene Erklärung in der Präsentationsschicht.

Dirk Dorsch


Werfen, schlucken, checked oder unchecked? Altbekannte Diskussionen um einen oft stiefmütterlich behandelten Aspekt der Applikationsentwicklung. Die fachlichen Anforderungen stellen eher die positiven Aspekte der User Journey in den Vordergrund. Fehler werden häufig ignoriert. Angesichts der unstreitigen Existenz von Exceptions eine eher naive Herangehensweise. Eine kreativ gestaltete Fehlerseite für ein „Page not found“ oder einen „Internal Server Error“ entlockt dem Besucher ein Schmunzeln und kann zu tieferem Verständnis beim weiteren Umgang mit dem System führen. Eine Seite ohne jegliche Erklärung führt hingegen schnell zu Verbitterung und sinkender Akzeptanz. In Zeiten von API Economy entscheidet die Attraktivität eines API über den wirtschaftlichen Erfolg eines Vorhabens. Bei der Evaluation zweier APIs kommt es unweigerlich zu fehlerhaften Aufrufen. „500 Internal Server Error“ oder „400 – Bad Request, der Wert 0 im Feld ID ist ungültig“ – wofür würden Sie sich entscheiden?

Selbst wenn das äußere Erscheinungsbild irrelevant ist, bleibt ein wohldurchdachtes Exception Handling für den Betrieb einer Anwendung unabdingbar. Ein konsistentes Logging ist das Minimum, und der Support dürfte aussagekräftige Fehlermeldungen begrüßen. Während der Entwicklungsphase ist die Ausgabe des vollständigen Stacktrace im Browser zu Debuggingzwecken ein oft gewähltes Mittel, im Produktivsystem jedoch ein klares No-Go. Um den infrastrukturellen Aspekt des Exception Handling im Projekt schnell zu erledigen, ist der Kompromiss häufig eine generische Fehlermeldung. Wahlweise als HTML oder als JSON in der API-Response. Zwar gelangen so keine Systeminterna an böswillige Aufrufer, allerdings geht die Aussagekraft für den Besucher gegen null. Einen verwertbaren Hinweis für die weitere Fehlersuche gibt es ebenfalls nicht. Darüber hinaus sind generische Fehlerseiten durch das Framework gestellt und meist nicht in das App-Layout integriert. Der optische Bruch in einer Webapplikation macht keinen guten Eindruck, genau wie eine Abweichung von der Responsestruktur des API. Zu Beginn des Projekts ein tragfähiges Konzept zu definieren und in die Applikation zu integrieren ist deshalb empfehlenswert. Spring MVC bietet unterschiedliche Ansätze, die je nach Applikationstyp unterschiedlich gut passen. Darüber hinaus beinhaltet das Framework einen einfach integrierbaren Default, der für einige Anwendungen völlig ausreicht.

Checked or Unchecked

Einige strittige Punkte in Sachen Softwareentwick...

Java Magazin
Exception Handling für APIs und Web-Apps mit Spring MVC

Ausnahmen sind die Regel

Ernstzunehmende Fehler im Programmablauf, fehlerhafte Benutzereingaben, der Aufruf eines ungültigen URL: Ausnahmen sind die Regel. Überdies können Exceptions durchaus ausdrucksvolle Stilmittel des Programmflusses sein. Sie sind Teil der Interaktion mit der Applikation und ein nicht zu unterschätzender der Teil der User Experience. Entscheidend ist der Umgang mit einer Exception und eine angemessene Erklärung in der Präsentationsschicht.

Dirk Dorsch


Werfen, schlucken, checked oder unchecked? Altbekannte Diskussionen um einen oft stiefmütterlich behandelten Aspekt der Applikationsentwicklung. Die fachlichen Anforderungen stellen eher die positiven Aspekte der User Journey in den Vordergrund. Fehler werden häufig ignoriert. Angesichts der unstreitigen Existenz von Exceptions eine eher naive Herangehensweise. Eine kreativ gestaltete Fehlerseite für ein „Page not found“ oder einen „Internal Server Error“ entlockt dem Besucher ein Schmunzeln und kann zu tieferem Verständnis beim weiteren Umgang mit dem System führen. Eine Seite ohne jegliche Erklärung führt hingegen schnell zu Verbitterung und sinkender Akzeptanz. In Zeiten von API Economy entscheidet die Attraktivität eines API über den wirtschaftlichen Erfolg eines Vorhabens. Bei der Evaluation zweier APIs kommt es unweigerlich zu fehlerhaften Aufrufen. „500 Internal Server Error“ oder „400 – Bad Request, der Wert 0 im Feld ID ist ungültig“ – wofür würden Sie sich entscheiden?

Selbst wenn das äußere Erscheinungsbild irrelevant ist, bleibt ein wohldurchdachtes Exception Handling für den Betrieb einer Anwendung unabdingbar. Ein konsistentes Logging ist das Minimum, und der Support dürfte aussagekräftige Fehlermeldungen begrüßen. Während der Entwicklungsphase ist die Ausgabe des vollständigen Stacktrace im Browser zu Debuggingzwecken ein oft gewähltes Mittel, im Produktivsystem jedoch ein klares No-Go. Um den infrastrukturellen Aspekt des Exception Handling im Projekt schnell zu erledigen, ist der Kompromiss häufig eine generische Fehlermeldung. Wahlweise als HTML oder als JSON in der API-Response. Zwar gelangen so keine Systeminterna an böswillige Aufrufer, allerdings geht die Aussagekraft für den Besucher gegen null. Einen verwertbaren Hinweis für die weitere Fehlersuche gibt es ebenfalls nicht. Darüber hinaus sind generische Fehlerseiten durch das Framework gestellt und meist nicht in das App-Layout integriert. Der optische Bruch in einer Webapplikation macht keinen guten Eindruck, genau wie eine Abweichung von der Responsestruktur des API. Zu Beginn des Projekts ein tragfähiges Konzept zu definieren und in die Applikation zu integrieren ist deshalb empfehlenswert. Spring MVC bietet unterschiedliche Ansätze, die je nach Applikationstyp unterschiedlich gut passen. Darüber hinaus beinhaltet das Framework einen einfach integrierbaren Default, der für einige Anwendungen völlig ausreicht.

Checked or Unchecked

Einige strittige Punkte in Sachen Softwareentwick...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang