Re: [Jersey] exception handling best practices

From: Chris Carrier <>
Date: Mon, 22 Feb 2010 10:04:43 -0800

But it's true that one would need a new ExceptionMapper for every new
Exception type? I guess it's somewhat a question of taste but for me

catch (RecordNotFoundException e){
  return Response.status(Response.Status.NOT_FOUND).entity(e.getMessage).build;

Is much simpler and more self-documenting than:

public class RecordNotFoundExceptionMapper implements
ExceptionMapper<RecordNotFoundException> {
  public Response toResponse(RecordNotFoundException ex) {
        return Response.status(404).entity(ex.getMessage()).build();

It would be lovely if everyone who might be looking at my code will be
familiar with the details of Jersey but I work in a company and that's
just not the way things work. I would rather my code is
self-documenting and clear for anyone who is familiar with Java than
hope that the person knows about Jersey's Provider magic.

That's most of what I like about Jersey. Anyone can look at a method
annotated with @GET @Consumes etc and it's pretty clear what is
happening there even if you've never heard of JAX-RS.

Like I said though at some point it's a matter of taste. Both
approaches have their downsides.


On Mon, Feb 22, 2010 at 9:50 AM, Moises Lejter <> wrote:
> Hmm - I would have thought it would go the other way ...
> Using the "string of catch clauses", there is boilerplate in every class
> that can run into a specific domain exception, to list the code to run in
> that case.  Using the ExceptionMappers, the code for a specific domain
> exception is listed exactly once, in the ExceptionMapper for that one
> class...
> It is true that using ExceptionMappers things are more decentralized, and
> people have to know JAX-RS/Jersey ... But as to the second - if they don't,
> maybe they shouldn't be maintaining those HTTP classes?
> Moises
> On Mon, Feb 22, 2010 at 11:44 AM, Chris Carrier <> wrote:
>> That might be true I was just throwing out my approach.  Personally
>> I'm not a huge fan of the @Provider mechanism as it's not intuitive.
>> You just have to know how Jersey/JAX-RS works and that there are these
>> magic provider classes that may be configuring behavior.  I'd rather
>> keep things simple and use as much plain Java as possible.  I don't
>> think the string-of-catches will be a problem upkeep wise and anyone
>> else can look at my code and pretty much understand what's going on.
>> Using the exceptionMapper would you have an individual mapper for
>> every exception type?  Seems like a ton of boilerplate.
>> Chris
>> On Mon, Feb 22, 2010 at 9:32 AM, Moises Lejter <>
>> wrote:
>> > Hmm - if by "HTTP classes" you mean those annotated with JAX-RS/jersey
>> > annotations, then I think Marc was talking about using ExceptionMapper
>> > classes to capture the service-layer exceptions, then returning an HTTP
>> > response with the proper status code and message, taken from those
>> > exceptions.  As a result, you would not need that "string of catch
>> > clauses"
>> > - your HTTP classes would simply ignore exceptions, and concentrate on
>> > the
>> > "correct" scenario, and the ExceptionMappers would be invoked by Jersey
>> > on
>> > its own, when the HTTP class throws an exception that it doesn't handle
>> > (namely, your domain exceptions from the service layer), and compute and
>> > return the right error status code and message for you...
>> > No string of catch clauses => more maintainable code?
>> > Moises
>> >
>> > On Mon, Feb 22, 2010 at 11:18 AM, Chris Carrier <>
>> > wrote:
>> >>
>> >> The approach I landed on was to keep the HTTP error handling as
>> >> contained in the Jersey annotated endpoint classes as possible.  So
>> >> basically from my HTTP classes I delegate to some kind of service
>> >> class layer.  So if I am trying to post an account or something I
>> >> would create an Exception maybe something like
>> >> 'AccountCreationException', 'AccountValidationException' etc that get
>> >> thrown from the service layer.  Then in my HTTP class I simply catch
>> >> those and map them to whatever status code I want
>> >> (AccountNotFoundException -> 404 etc...).  And since the exceptions
>> >> were raised in the service layer they already contain a human readable
>> >> error message.  It keeps it pretty manageable because there is just a
>> >> string of catch clauses that handle your HTTP error mapping.
>> >>
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail: