3

I would like to throw Exceptions from my REST endpoints. However, I am not too familiar with good REST design techniques. Consider the following...

//note the throws clause
@POST
public Response saveNewActivity(@HeaderParam("sessionTokenString") String sessionTokenString, Activity activity) throws Exception {
    Activity result = as.saveNewActivity(activity);
    if (result == null) {
        throw new DuplicateDataException("blah blah blah");
    }
    return Response.ok(result).build();
}

versus handling Exceptions and explicitly returning only responses

@POST
public Response saveNewActivity(@HeaderParam("sessionTokenString") String sessionTokenString, Activity activity) {
    try {
        Activity result = as.saveNewActivity(activity);
        if (result == null) {
            throw new DuplicateDataException("blah blah blah");
        }
        return Response.ok(result).build();
    } catch (Exception e) {
         return Response.status(Response.Status.SOME_STATUS).build();
    }
}

I can have the DuplicateDataException mapped using ExceptionMapper as follows

public class DuplicateDataExceptionMapper implements ExceptionMapper<DuplicateDataException> {

    @Override
    public Response toResponse(DuplicateDataException e) {
        ErrorMessage errorMessage = new ErrorMessage ("Activity names must be unique.", <HttpStatusNumber>, "<add documentation here>");
        return Response.status(Status.NOT_FOUND).entity(errorMessage).build();
    }
}

Although in the end a Response gets returned anyways, but is one way of handling Exceptions (whether or not they are RuntimeExceptions) preferred over another, or does it not really matter? I have never seen a throws statement on a REST endpoint which is why I ask.

Please note that this question or this question did not give the answer I am looking for.

Community
  • 1
  • 1
Rob L
  • 3,073
  • 6
  • 31
  • 61
  • 3
    [`ExceptionMapper` exists for a reason, it is the idiomatic way to handle exceptions so use it.](https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ExceptionMapper.html) Any opinion about throwing an exception as *good/bad* design is just that **opinion** especially since a specific way of dealing with all exceptions from a service call is provided with `ExceptionMapper`. –  Jul 04 '15 at 15:00

2 Answers2

1

It is a bad idea to through an exception.

From the client perspective it results in an http 500 error code that don't tell nothing to an automatic program.

You should design your code trying to intercept all possible errors and reply with an appropriate error code inside your valid response. If your response in a json answer with something like the following:

{
    statusCode: 345,
    errorMessage: 'The error code message'
}

Leave the http status code 500 to unexpected errors.

Davide Lorenzo MARINO
  • 26,420
  • 4
  • 39
  • 56
1

If a parent class is catching the thrown exception and returning an appropriate HTTP Reponse error code (4xx), the initial code is fine.

If there's no parent class catching these to make them a 4xx instead of a 500, your code - to change the response code to something appropriate for this specific error - seems like a really good idea.

Dean J
  • 39,360
  • 16
  • 67
  • 93