users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Exceptions for representing HTTP errors

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 15 May 2012 13:56:39 -0400

On 5/15/12 1:43 PM, Marek Potociar wrote:
>
> On May 15, 2012, at 12:38 PM, Sergey Beryozkin wrote:
>
>> I prototyped few exceptions for representing the most important HTTP errors, with the most exceptions from the original Bill's list added.
>> I've attached a git patch to [1] - I'd prefer to contributing this way if possible. The patch, if approved, can be easily recreated, I used 'git diff master'.
>
> Thanks, that is a reasonable first start. See few comment bellow.
>
>>
>> I chose to add a new javax.ws.rs.errors package to minimize the 'noise' in other packages.
>
> Unless we want to use the exceptions on the server side only, I think the exceptions should go into the root package where the WebApplicationException is placed already.
>
>> I was not sure about NotAuthorizedException. Many users find the difference between 401 and 403 confusing. I guess having NotAuthorizedException won't help in this regard. Perhaps it's better to leave the security-related exceptions...
>
> Perhaps we should explicitly support 401, but ignore 403? I can see that 401 will be useful for checking for "authorization required" issues. I don't have a good use case for a special 403 exception. Typically 403 scenarios are masked as 404 IRL anyway.
>
> Also, I think we should be able to set a custom status code on InternalServerErrorException exception (and rename it to ServerErrorException) to capture all 5xx as a group. Perhaps we also need a ClientErrorException as a root for all 4xx errors? And RedirectionExcetion for 3xx?
>
> Also, provided we want to use these on client side too, I think we need to provide exception constructors that take Response object as an argument, so that the original message from the server is not lost when converting the response into an exception and re-throwing it on the client side.
>

I agree mostly with Marek. iMO, I don't see the problem with having both
fine-grain exceptions for each and *every* code and family super
classes. Really what is the harm? Especially if you put them in a
separate package? The exception classes would be really really
simple... Additionally, maybe 3xx have a helper method that returns the
redirect URL. 503 has a helper method returning the Retry-After header,
etc...

RedirectException
    MultipleChoicesException
    MovedPermanentlyException
    ...
ClientErrorException
    BadRequestException
    ...
ServerErrorException
    InternalServerErrorException
    ...
    ServiceUnavailableException
    ...




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com