Spring Boot WebClient ErrorHandling

[OnDemand]

Hallo zusammen,

ich möchte in unserer neuen Api WebClient nutzen (Nachfolger von RestTemplate). Dabei möchte ich das Exceptionhandling gleich sauber einbauen. Bisher hab ich das immer so pi mal daumen gemacht und nicht wirklich sauber.

Wir geht ihr dabei vor? Catched ihr die Exception direkt da, wo der API Aufruf gemacht wird oder gebt ihr den "eine Etage" weiter an den Aufrufer der Methode?
Schwer zu verstehen wahrscheinlich, was genau ich meine. Vielleicht kennt jemand eine gute Resource auf GitHub die einen API Client wiklich sauber eingebaut hat, in der man sich was abschauen kann?

Ich hab zb ein Klasse die per Quartz angestoßen wird und dann entsprechend die Daten an die API schickt oder holt.
Dummycode:

class Datenabgleich(){
    
    starteDatenabgleich(){
        //Hole Daten aus DB
        apiEndpoint.put(Objekt meinObjekt);
    }
}

und eine Klasse welche die API Schnittstelle ist

class ApiSchnittstelle(){
    
    Objekt put(Objekt objekt){
//hier auch das try catch oder lieber throws in der Methodensignatur und das an den Aufrufer delegieren, damit der entsprechend reagieren kann?
         webClient.put(objekt)
   }
    
    Objekt post(Objekt objekt){
        webClient.post(objekt)
    }
}

 

[mrBrown]

Catched ihr die Exception direkt da, wo der API Aufruf gemacht wird oder gebt ihr den "eine Etage" weiter an den Aufrufer der Methode?

Grundsätzlich nahezu immer letzteres – mit Ausnahmen, bei denen "Fehler" in Form von Exceptions erwartbar sein können und es sinnvolle Reaktionen darauf gibt (bspw. API wirft eine Exception, wenn "suche alle XY" keine Ergebnisse liefert, die (konkrete!) Exception direkt zu fangen und dann zB eine leere Liste zu liefern).

 

[OnDemand]

die (konkrete!) Exception direkt zu fangen und dann zB eine leere Liste zu liefern).

so hab ich es bisher auch gemacht. Oder ein NULL wenn eine Entität abgefragt wird. Das dumme ist, dass manche API Dokus keine Fehler ausgeben in der Dokumentation, man tappt dann im dunkeln und muss alle Eventualitäten bedenken, die vielleicht auftreten könnten. Im absoluten Ausnahmefall geb ich dann null zurück

 

[mrBrown]

Das dumme ist, dass manche API Dokus keine Fehler ausgeben in der Dokumentation, man tappt dann im dunkeln und muss alle Eventualitäten bedenken, die vielleicht auftreten könnten.

Mit Exceptions lässt sich das doch relativ einfach abfrühstücken?

ich möchte in unserer neuen Api WebClient nutzen (Nachfolger von RestTemplate

Nur so am Rande: ist das wirklich der Nachfolger (also RestTemplate deprecated und damit ersetzt)? Ob man die reaktive Variante nutzen will, ist eher eine Frage der ganzen Architektur und weniger von "ist neuer".

Im absoluten Ausnahmefall geb ich dann null zurück

null ist btw fast nie sinnvoll Da ist Optional (wenn es ein oder kein Wert ist) oder eine leere Liste (wenn es beliebig viele sind) meist der bessere Weg.

 

[OnDemand]

Optional, stimmt daran hab ich noch gar nicht gedacht!

Was ich so lese, heisst es, dass Webclient der Nachfolger ist. Hmm ist mir aber grad auch iwie Schnitte, hab mich mit RestTemplate gut angefreundet, werde ich vermutlich auch weiter nutzen.

 

[LimDul]

Grundsätzlich nahezu immer letzteres – mit Ausnahmen, bei denen "Fehler" in Form von Exceptions erwartbar sein können und es sinnvolle Reaktionen darauf gibt (bspw. API wirft eine Exception, wenn "suche alle XY" keine Ergebnisse liefert, die (konkrete!) Exception direkt zu fangen und dann zB eine leere Liste zu liefern).

Sehe ich genau so. Eine Exception wird:
* Entweder weitergeworfen
* In eine andere Exception gewrapped
* Fachlich sinnvoll behandelt

Das heißt, an den Stellen, wo ich sie behandeln kann, behandle sie fachlich (Sei es durch Umwandlung in Fehlermelden, oder wie beschrieben durch Rückgabe einer leeren Liste etc.)

Auf welcher Ebene das ist, ist sehr unterschiedlich. Manchmal ist es tief unten in der Anwendung, das nur protokolliert und nach oben einfach "Kein Ergebnis" gemeldet wird. Manchmal ist weiter oben - dafür wrappen wir ggf. technische Exception-Klasse z.B. in eine eigene XYServiceException, weil die Stelle die das Handling macht sich nicht dafür interessieren soll ob es eine JAXB, RestEasy, IOException oder sonst was ist. Sprich an den Stellen, wo der Aufrufer der Methode nichts mehr von der Technologie dahinter sehen soll, wird die Exception gewrapped.

Und wenn ich gar nicht damit umgehen kann laufe ich halt in das Standardfehlerhandling rein und die Anwendung schmiert ab und protokolliert das. Sollte man vermeiden, ist aber meines Erachtens besser als Fehler "silent" zu verschlucken, weil man nicht weiß wie man sie behandeln soll.