Patrick Schnell Selbstständig

Eine API-Abfrage mit ungültigen oder gar fehlenden Parametern sollte unbedingt vermieden werden. Sollte dies nicht möglich sein, kann ähnlich wie bei einer fehlenden Autorisierung in der Clientanwendung entsprechend darauf reagiert werden.

Fehlerbehandlung – ein meist ungeliebter und vor allem nach hinten geschobener Aspekt in der Softwareentwicklung: „Welche Fehler? Was soll denn schon passieren?“ Wenn auf die Validität von Argumenten eines Aufrufs oder Ähnliches geprüft wird, werfen viele Entwickler einfach eine der zahlreichen in .NET vorhandenen Standard-Exceptions. Doch was passiert danach, und vor allem: Welchen Informationsgehalt benötigen Fehler?

Im Zuge der serviceorientierten Architektur vieler Systeme rückt die Fehlerbehandlung immer mehr in den Fokus. Die an den Service angebundenen Anwendungen wie zum Beispiel Webclients oder mobile Apps benötigen aussagekräftige und standardisierte Fehlermeldungen, auf die reagiert werden kann. Ein einfacher HTTP-Status reicht hier genauso wenig wie ein allgemeiner Fehlertext. In diesem Artikel werde ich Ihnen aufzeigen, wie mittels ASP.NET Core ein zentrales Fehlerhandling inklusive aussagekräftiger Fehlerinformationen umgesetzt werden kann. Dies ermöglicht ein ebenfalls zentrales Fehlerhandling in Ihren Endanwendungen, die im besten Fall so generisch wie möglich umgesetzt werden können.

Fehler verstehen

Hier stellt sich die Frage, in welchen Situationen ein Fehler provoziert wird und an welchen Stellen in der Anwendung ein Fehler unbehandelt bzw. ungewünscht auftreten kann, denn Fehler sind prinzipiell nicht immer etwas Schlechtes. In die erste Kategorie fallen zum Beispiel Fehler, die mit der Authentifizierung oder Autorisierung zu nennen sind, egal ob es sich nun um das fehlende Anmeldetoken, keine ausreichenden Rechte oder eine unzureichende Lizenzierung handelt. Dies sind gewünschte Fehler, die durch die Anwendungslogik provoziert werden können. Auf der Gegenseite (zum Beispiel einer mobilen App oder einer Webanwendung) ist es hierbei ebenfalls notwendig, möglichst an einer zentralen Stelle auf diese Fehler reagieren zu können, um zum Beispiel auf die Anmeldeseite zu springen. Zu dieser Kategorie zählen zudem auch Fehler wie unter anderem Validierungsfehler oder ungültige Argumente (z. B. OutOfRangeExceptions oder ArgumentNullExceptions). Hierbei sollte auf Clientseite bereits im Voraus alles unternommen werden, damit diese Fehler nicht auftreten können. Eine API-Abfrage mit ungültigen oder gar fehlenden Parametern sollte unbedingt vermieden werden. Sollte dies nicht möglich sein, kann ähnlich wie bei einer fehlenden Autorisierung in der Clientanwendung entsprechend darauf reagiert werden. Die zweite Kategorie an Fehlern sind diejenigen, die es auf jeden Fall zu vermeiden gilt und selbst für die Clientanwendung nicht behandelbar sind. Dies sind zum einem Fehler wie z. B. NullReferenceExceptions oder Ähnliches, die den vorgesehenen Programmablauf unter- bzw. abbrechen. Solche Fehler müssen ebenfalls dem Client in einer Art und Weise mitgeteilt werden, dass dieser darauf reagieren kann (zum Beispiel durch Darstellen des Fehlers inklusive aussagekräftiger Fehlermeldung), auch wenn er den Fehler nicht zwingend behandeln kann.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 4.18 - "Eine Frage der Architektur"

Alle Infos zum Heft
579830388Zentrales Exception Handling für Web-APIs in ASP.NET Core
X
- Gib Deinen Standort ein -
- or -