jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Concerns about the client-side exception hierarchy

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 21 Feb 2012 17:06:42 +0000

On 21/02/12 10:53, Marek Potociar wrote:
>
>
> On 02/20/2012 03:35 PM, Sergey Beryozkin wrote:
>> Here is my proposal.
>>
>> 1. WebApplicationException serves as the base exception indicating that a problem has occurred at the server side.
>> - this exception can be thrown on the server side by the runtime or the application code
>> - this exception can be thrown on the client side by the runtime processing the HTTP response containing a status code
>>> = 400.
>> - this exception class can serve as the base for finer-grained exceptions, example:
>>
>> public class NotFoundException extends WebApplicationException {
>> public NotFoundException() {
>> super(404);
>> }
>> }
>>
>> thus making NotFoundException/etc also catchable on the client side with the code checking for WebApplicationExceptions...
>>
>> 2. Existing InvocationException gets removed
>
> Sounds good.
>
> What are the specific exceptions proposed for inclusion in the spec?
>

No new exceptions are to be *initially* added according to this specific
proposal but it makes it possible to add finer-grained exceptions
extending the base ones.

- WebApplicationException serves as the base for all the problems
originated at the server side.
- ClientException continues to be the base exception representing some
sort of the client-side error but also enhanced at the cost of
InvocationException which is to be dropped

If we all agree that it makes sense so far then lets review next what
additional exceptions such as NotFoundException, etc, representing
server-side exceptions, can be added.

Bill proposed few exception classes; IMHO we should limit the number to
the ones representing the most common HTTP error code, here is the
Bill's list:

MethodNotAllowedException
BadRequestException
NotAcceptableException
InternalServerErrorException
UnauthorizedException
UnsupportedMediaTypeException
NotFoundException

I'd drop BadRequestException - this can be anything, and as such the
base WebApplicationException can do to deal with it.
InternalServerErrorException, UnauthorizedException should probably go
too, leaving

MethodNotAllowedException
NotAcceptableException
UnsupportedMediaTypeException
NotFoundException


>>
>> 3. Existing ClientException gets the getResponse() method added.
>>
>> 4. As far as the client is concerned,
>> WebApplicationException and its possible subclasses would indicate that the server response is a fault of some sort
>>
>> 5. ClientException will *only* indicate that the problem has occurred on the client side. As suggested in 3 it will be
>> nearly identical to the existing ClientException but will have a getResponse() added.
>>
>> Note that its getResponse() method will return 'null' for all the cases except when the failure was caused by the client
>> runtime unable to process the server response (ex, no MBR was found).
>
> You seem to ignore the possibility of client-side processing failing in a request filter/handler chain. Would it make
> sense to also add Request to the client exception?

OK

> How about approaching this also with a small set of more specific
> child exceptions?
>
Do you mean ConnectionFailedException and few others ? I'd probably add
ConnectionFailedException for a start...

Cheers, Sergey

> Marek
>