Re: [Jersey] exception handling best practices

From: Felipe Gaucho <>
Date: Mon, 22 Feb 2010 18:09:06 +0100

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: