Java >> Java Tutorial >  >> Tag >> Spring

Behandeln Sie nicht erfasste Ausnahmen in einer Spring-Boot-REST-API – Teil VI

Spring

Wir haben oft gesehen, dass auf Ihrer Webseite eine Ausnahme ausgelöst wurde, und der gesamte Stack-Trace der Ausnahme. Ein technisch nicht versierter Benutzer wird die meiste Zeit nicht verstehen können. Auch Stack-Trace ist nicht die beste Option, wenn wir den gleichen Ausnahmefehler im netten JSON-Format mit der Grundursache anzeigen können. In diesem Beitrag zeigen wir, wie man mit uncaught umgeht Ausnahmen von unserer vorherigen Spring-REST-API, die wir hier erstellt haben.

Diese spezielle Funktion zeigt, wie man mit den meisten HTTP 500 umgeht Fehler, die aufgrund serverseitiger Probleme auftreten. Alle Fehler auf Anfrage- oder Clientseite, das sind HTTP 400 Fehler und sie wurden im vorherigen Beitrag Fehlerbehandlung in der Spring Boot Rest API behandelt.

Problem nicht abgefangener Ausnahmen

Erstens, was passiert, wenn es ein Problem mit der Datenbankverbindung gibt? OR-Spalten in Ihrer REST-API unterscheiden sich von den Angaben in Datenbanktabellen? Ihre API gibt einen 500-Fehler aus, und wenn Sie keinen Mechanismus haben, zeigt dies einen Fehler in einem HTML-Format an, das dem Benutzer oder Entwickler nicht viele Informationen zur Lösung des Problems gibt. Das Anzeigen eines solchen Stack-Trace auf einer Webseite für den Endbenutzer ist aus Programmierperspektive ein schlechtes Beispiel.

Lösung

JAX-RS bietet eine Möglichkeit, nicht abgefangene Ausnahmen zu behandeln. Dies kann durch meine Implementierung einer Schnittstelle für ExtendedExceptionMapper erfolgen . Im Grunde ist dies ein Vertrag für einen Anbieter, der Java-Ausnahmen akzeptiert und sie einem Antwortobjekt zuordnet, das in JSON umgewandelt werden kann. Dies kann wie folgt implementiert werden:

package com.betterjavacode.benefits.utilities;

import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.Status;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.glassfish.jersey.spi.ExtendedExceptionMapper;

@Provider
public class UncaughtExceptionMapper implements ExtendedExceptionMapper<Throwable> 
{

   private static final Logger LOGGER = LogManager.getLogger(UncaughtExceptionMapper.class);

   @Override
   public Response toResponse(Throwable exception) 
   {
     LOGGER.info("Enter >> toResponse ");
     LOGGER.debug("Exception Caught: " + exception.getMessage());
     LOGGER.info("Exit << toResponse");
     return Response.status(Status.BAD_REQUEST)
       .entity(exception.getMessage())
       .build();
   }

   @Override
   public boolean isMappable(Throwable arg0) 
   {
     return !(arg0 instanceof WebApplicationException);
   }

}

Grundsätzlich zeigt diese Implementierung eine Klasse `UncaughtExceptionMapper`  Implementieren einer Schnittstelle `ExtendedExceptionMapper`, die eine Möglichkeit bietet, alle Ausnahmen abzubilden, die nicht vom Typ WebApplicationException sind (Die meisten HTTP 400-Fehler sind WebApplicationExceptions ). toResponse -Methode hilft, alle Ausnahmen zu protokollieren und Ausnahmen in ein Response-Objekt umzuwandeln.

Schlussfolgerung

Abschließend haben wir gezeigt, wie alle nicht behandelten Ausnahmen für eine nette Antwort in das JSON-Format abgebildet werden. Der Code für diesen Beitrag ist im Github-Repository verfügbar.


Java-Tag