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: Thu, 1 Mar 2012 12:11:19 +0000

by the way, just spotted

http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/core/MessageProcessingException.java?rev=62bb71340b7c156684858dac5c9af09aec50430c

Should that be gone ? as a summary we seem to have agreed:

- WebApplicationException serves as the base server side exception and
can be used on both ends
- a limited number of child WebApplicationExceptions is introduced
- InvocationException gets removed
- ClientInvocation is 'promoted' to represent the base client-side exception
- a limited number of child ClientExceptions is introduced

Sergey



On 22/02/12 15:11, Sergey Beryozkin wrote:
> Sounds like we agree more than we disagree :-)
> Either way, I support your idea that having the child exceptions can be
> liked by some/quite a few users,
>
> Cheers, Sergey
>
> On 22/02/12 15:00, Bill Burke wrote:
>>
>>
>> On 2/22/12 9:10 AM, Sergey Beryozkin wrote:
>>> On 22/02/12 13:41, Bill Burke wrote:
>>>>
>>>>
>>>> On 2/22/12 8:07 AM, Sergey Beryozkin wrote:
>>>>> Hi Bill
>>>>> On 22/02/12 12:46, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 2/21/12 12:06 PM, Sergey Beryozkin wrote:
>>>>>>> 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...
>>>>>>>
>>>>>>
>>>>>> I agree with adding COnnectionFailedException, I don't agree with
>>>>>> removing the excerptions you suggested.
>>>>>>
>>>>>>
>>>>> It's really to do with coming up with some very minimal set, as
>>>>> opposed
>>>>> to saying that no, BadRequestException, can not occur often enough.
>>>>>
>>>>> For ex, BadRequestException, can be thrown in a number of cases, and
>>>>> thus it's no more useful on the client side than the base
>>>>> WebApplicationException...Same for InternalServerErrorException.
>>>>>
>>>>> UnauthorizedException - may be should stay, though the jaxrs runtime
>>>>> itself won't throw it...
>>>>>
>>>>> It's not a big deal, if we were indeed to go for adding few child
>>>>> exceptions, if we had 5 or 8 added, the question is how far should we
>>>>> really go... I guess I'm still worried about the class explosion more
>>>>> than anything else :-)
>>>>>
>>>>
>>>> Well, the JAX-RS 2.0 spec is inconsistent on this sort of thing. We
>>>> have
>>>> methods in request/responsebuilder for http headers that are rarely
>>>> used
>>>> (allow for example) and don't have ones for things that are often used
>>>> (accept).
>>>>
>>>> We should do one or the other across the board. IMO, I don't see the
>>>> problem with an explosion of methods/classes that cover hte HTTP
>>>> specification. While Sergey may find BadRequestException unuseful,
>>>> somebody else might.
>>> I think you've misinterpreted me. I was talking about the utility of
>>> BadRequestException while trying to justify the conservative approach
>>> which I believe the spec should take with regard to introducing new
>>> classes which to be honest do not add anything new, example, that is all
>>> is already covered by the spec/api. That said, I'm not going to spend
>>> much time on arguing against extra 3 or whatever classes
>>>
>>
>> I think you misunderstood me :) If you look at RequestHeader or
>> RequestBuilder, for example, there's methods there that would rarely be
>> used (i.e. allow). I'm saying either we cover everything or we be
>> consistent throughout the spec and remove classes/methods that will
>> rarely (if ever) be used.
>>
>>


-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com