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.
Chris
On Mon, Feb 22, 2010 at 9:09 AM, Felipe Gaucho <fgaucho_at_gmail.com> 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 <Florian.Hehlen_at_imc.nl> 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: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>