Re: [Jersey] exception handling best practices

From: Chris Carrier <>
Date: Mon, 22 Feb 2010 09:18:01 -0800

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.


On Mon, Feb 22, 2010 at 9:09 AM, Felipe Gaucho <> wrote:
> Keep with the http codes and perhaps a human readable message....
> Java stack trace has no meaning for non-Java clients...
> On 22.02.2010, at 17:54, Florian Hehlen <> wrote:
>> Hi,
>> I am wondering if there is a recommended way to map exceptions with
>> jax-rs/jersey. I have been playing around with all the different exceptions
>> that extend WebApplicationException, I have in some cases just pushed
>> runtime exceptions back to the framework, and I have also considered using
>> the ExceptionMapper interface. I realize that I could extend
>> WebApplicationException to create my own exceptions aswell, but is that
>> wise?
>> - I would like to have the most consistent relationship between
>> application exceptions/errors and HTTP codes.
>> - I would also like to guarantee that a human readable message and a
>> stacktrace travel with all my errors back to the client. Yet it seems that
>> this happens with certain types of exceptions but not with others.
>> -I would also like to spend the least amount of time/energy on maintaining
>> all these different possible states.
>> Is there one approach that's better than others? I can't at first glance
>> see one. Am I missing something? Does anyone have any recommendations
>> experiences?
>> Cheers,
>> Florian
>> The information in this e-mail is intended only for the person or entity
>> to which it is addressed.
>> It may contain confidential and /or privileged material.  If someone other
>> than the intended recipient should receive this e-mail, he / she shall not
>> be entitled to read, disseminate, disclose or duplicate it.
>> If you receive this e-mail unintentionally, please inform us immediately
>> by "reply" and then delete it from your system. Although this information
>> has been compiled with great care, neither IMC Financial Markets & Asset
>> Management nor any of its related entities shall accept any responsibility
>> for any errors, omissions or other inaccuracies in this information or for
>> the consequences thereof, nor shall it be bound in any way by the contents
>> of this e-mail or its attachments.  In the event of incomplete or incorrect
>> transmission, please return the e-mail to the sender and permanently delete
>> this message and any attachments.
>> Messages and attachments are scanned for all known viruses. Always scan
>> attachments before opening them.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: