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

From: Sergey Beryozkin <>
Date: Wed, 16 May 2012 11:37:15 +0100

See the updated patch at [1], changes:

1.ResourceGoneException added
2.InternalServerExceptionError renamed to ServerExceptionError
3.All exception classes support constructors accepting, ServerExceptionError also has constructors
accepting individual status codes

More comments below on NotAuthorizedException:

On 15/05/12 21:02, 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 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.

NotAuthorizedException can easily be added. My concern it will not help
users to understand whether it means that a client failed to
authenticate or the resulting security context was not enough to pass
through say the RBAC barrier. It is just confusing IMHO.
By the way, I wrote myself few demos returning 403 returning in case of
the RBAC failures (authorization) and 401 - in case of authentication
failures. May be I was wrong with my interpretation of 403, but IMHO it
is confusing to use 401 mapped to 'NotAuthorizedException'.
If I were to choose between:

1. We have WebApplicationException which can always be used in cases
where no dedicated exception for a given status code exists - new
WebApplicationException(401) is still quite perfect


2. Add NotAuthorizedException

then I'd go for 1.

But I'm not sure it is worth spending much time on this specific issue,
so if people feel strongly about having a dedicated
NotAuthorizedException then so be it

Cheers, Sergey

>> 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,
>> 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