users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 16 May 2012 13:35:26 +0200

On May 15, 2012, at 10:02 PM, Sergey Beryozkin wrote:

> On 15/05/12 18:43, 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.
>>
>
> The reason I put it to the 'errors' sub-package (this is also a response to Santiago's comment) was that after some consideration I thought that in the context of RS services, exceptions representing individual HTTP errors may well go into the 'errors' sub-package.
> I'll keep prototyping using this package if you do not mind but feel free to move it to whatever package you think is best
>
>>> 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?
>
> OK
>
>> And RedirectionExcetion for 3xx?
>>
> I'm not comfortable with the idea of representing the redirects with exceptions, very often it is part of the overall application flow, as opposed to indicating that the resource has moved or something.
> May be MovedPermanentlyException ? We can always add new exceptions later on,

My thinking here was focused on the client side and I was considering following flow:

try {
    String response = target.request("text/plain").get(String.class);
    ...
} catch (RedirectionException ex) {
    // ok, seems I have a wrong link, let's try the correct link, if available
} catch (ClientErrorException ex) {
    // i sent a wrong request, let's try to fix it and resend
} catch (ServerErrorException ex) {
    // uups, there's nothing i can do about it
}

The above seems to make sense in theory, but I admit I am not sure if it would work well in practice. Perhaps a flat structure with exceptions dedicated to specific error codes is enough in the end.

In any case, what I am still missing in the solution is a proposal how to handle cases when application code throws directly a WAE with a code covered by a specific exception. Seems to me that for the exception mappers and client side to work correctly, we need to catch these and re-throw as the correct sub-type. Right?

Marek

>
>
>> 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.
>>
> OK
>
> Cheers, Sergey
>
>> Marek
>>
>>>
>>> After [1] is resolved I can prototype some code to do with the finer-grained client-only exceptions
>>>
>>> Sergey
>>>
>>> [1] http://java.net/jira/browse/JAX_RS_SPEC-195
>>
>
>