前端和后端之间的错误处理

Question

at work we building an web application with java spring backend and vue frontend. At the moment we uses 2 or 3 http response code to pass errors between frontend and backend. If you call and endpoint with wrong parameters, you'll get an BAD_REQUEST. If some exception was thrown in the backend (which isn't related with the parameters) the backend returns an INTERNAL_SERVER_ERROR and if you pass some ids which aren't in the database the backend returns an NOT_FOUND.

This method has multiple problems:

• we have no structure in error case which we can use to pass information to the user (frontend)
• we want to indicate problems to the user, which can't be classified by HTTP response codes. For example if an external service isn't available, we want to pass the service name to the frontend. But I don't know if "SERVICE_UNAVAILABLE" fits here...

I found this already: https://www.baeldung.com/spring-response-status-exception We could use the message field to pass detailed information about an error (specific error json in message field). Is this a good idea?

Opinions?

T

Answer 1

You can certainly pass information back in this field but using ResponseStatusException s. Depending on how much information the frontend needs (eg if it's just surfacing a user friendly message to the user) this may be enough for your needs.

Another approach, if you want to use a custom object in the response (esp. per exception/response code), is using @ControllerAdvice and extending ResponseEntityExceptionHandler .

eg say you have a custom exception ExternalServiceUnavailableException which had some underlying ServiceInformation you could retrieve from it. Then you could do something like

public class ServiceInformation {
    private final String name;
    private final String status;
    private final String statusMessage;

//snip
}

@ControllerAdvice
public class CustomResponseEntityExceptionHandler extends ResponseEntityExceptionHandler {
    @ExceptionHandler({ ExternalServiceUnavailableException.class })
    public ResponseEntity<Object> handleExternalServiceUnavailable(ExternalServiceUnavailableException ex, WebRequest request) {

        final ServiceInformation si = ex.getServiceInformation();
        return ResponseEntity
            .status(503) // or whatever code you want
            .body(si); // or map to some other object/format
        // or use the constructor to supply headers etc.
    }
}

When you throw a ExternalServiceUnavailableException this would result in a response body like

{
    "name": "my-external-service",
    "status": "timeout",
    "statusMessage": "Service timed out after 30 seconds"
}

A more complete example of this can be found in the below article where the same custom error object is used for each of the exceptions of consequence as well as a default handler.

https://www.baeldung.com/exception-handling-for-rest-with-spring

This makes it easier for the frontend to interpret (as does your proposed approach) since there is only a single format to expect and parse, but you are free to return different response shapes per exception.

Edit : it's worth remembering that there are also response codes 502 (bad gateway) and 504 (gateway timeout) which can be used to indicate an external service is either unavailable or timing out. If these are appropriate you could just use appropriate ResponseStatusExceptions with a message set to include the service name (or other info). As above, it depends on what you need/want the fronted to receive.