users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 28 Mar 2012 11:00:03 +0100

Sorry. the typo:
On 28/03/12 10:59, Sergey Beryozkin wrote:
> Continuing from the other thread:
>
>
> Note I'm not proposing for WAE to become the root exception type for all
> the exceptions which may originate from processing the HTTP request at
> the JAX-RS level but only for the exceptions identifying the server errors.
>
> The client code will be able to:

The *server* code will be able to:

>
> throw new WebApplicationException(400);
> throw new BadClientRequestException();
>
> I believe the runtime or custom user WebApplicationException mappers
> have to be able to catch BadClientRequestException. In this particular
> case it seems not intuitive to me having the two exception instances
> identifying the same error condition being not related to each other.
>
>
> Now, here is the client code:
>
> String string = request.get(String.class);
>
> We are thinking of introducing 5+ exceptions identifying the server
> errors (or errors reported by the server).
>
> Much depends upon what is decided on the relationship between
> WebApplicationException & exceptions like BadClientRequestException.
>
> I'd prefer them be related so that I can write on the client side:
> try {
> String string = request.get(String.class);
> } catch (NotFoundException ex) {
> // retry with the different address
> } catch (WebApplicationException ex) {
> // catches all the other errors reported by the server, including
> BadClientRequestException
> } catch (ClientException ex) {
> }
>
> The runtime maps the server error codes to individual exceptions such as
> NotFoundException, etc, assuming the matching classes are available,
> otherwise simply wrap it into WebApplicationException()
>
> Does it make sense ?
>
> Sergey
>
> On 27/03/12 17:29, Marek Potociar wrote:
>>
>> On Mar 25, 2012, at 7:07 PM, Sergey Beryozkin wrote:
>>
>>> Hi all,
>>>
>>> I'm having one particular concern/question about introducing child
>>> exceptions to do with individual error conditions (400, 404, etc).
>>>
>>> I think that introducing them will require the client runtime to
>>> throw those child exceptions instead of some base exception (such as
>>> WAE), otherwise the client code catching sat NotFoundException won't
>>> be executed if all the client runtime does is throws new
>>> WebApplicationException(404).
>>>
>>> Can we agree it would be the case ?
>>
>> Sounds reasonable to me (for the typed-response retrieval use case).
>>
>>> The other thing that needs to be agreed upon is this: the exceptions
>>> to do with the server errors are only thrown when a typed response is
>>> expected back, example,
>>>
>>> get(Book.class) or similar
>>
>> Yes that's the expectation.
>>
>> Marek
>>
>>> Sergey
>>>
>>> On 14/03/12 16:19, Sergey Beryozkin wrote:
>>>> Hi,
>>>> On 14/03/12 15:53, Marek Potociar wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> just wanted to check if there is any progress with the exception
>>>>> proposal write-up?
>>>>>
>>>>
>>>> I thought we came to the agreement - but I've cloned the repo and will
>>>> attach a diff to the JIRA with the proposed code changes - there might
>>>> be some delay but I'm on it
>>>>
>>>> thanks, Sergey
>>>>
>>>>> Thanks,
>>>>> Marek
>>>>>
>>>>> On 03/05/2012 09:23 PM, Santiago Pericas-Geertsen wrote:
>>>>>> Sergey,
>>>>>>
>>>>>> Still catching up with some e-mails. Do we already have a concrete
>>>>>> proposal for the exact number of client and server exceptions that we
>>>>>> want to include? If so, please point me to it. Otherwise, we should
>>>>>> put this in writing for the sake of this discussion. Did you
>>>>>> volunteer for that? ;)
>>>>>>
>>>>>> -- Santiago
>>>>>>
>>>>>> On Mar 5, 2012, at 11:06 AM, Sergey Beryozkin wrote:
>>>>>>
>>>>>>> Hi
>>>>>>> On 05/03/12 15:05, Santiago Pericas-Geertsen wrote:
>>>>>>>>
>>>>>>>> On Mar 1, 2012, at 7:41 AM, Sergey Beryozkin wrote:
>>>>>>>>
>>>>>>>>> On 01/03/12 12:11, Sergey Beryozkin wrote:
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ValidationException is there too - but that is OK -
>>>>>>>>> MessageProcessingException seem problematic though, MBR& MBW are
>>>>>>>>> typed to throw WebApplicationException& InputStream already
>>>>>>>>
>>>>>>>> Could you elaborate as to why you think it's problematic? I see
>>>>>>>> that it doesn't fit in the proposal that you have below, but what
>>>>>>>> if it extended WebApplicationException (client& server)?
>>>>>>>
>>>>>>> Sounds reasonable.
>>>>>>> The question is then, how it will 'co-exist' with other server side
>>>>>>> exceptions which are also WebApplicationException children ?
>>>>>>>
>>>>>>> Example, I'm assuming we will have BadClientRequestexception and
>>>>>>> ServerErrorException. The message read failure can be mapped to
>>>>>>> BadClientRequestException and the message write failure can be
>>>>>>> mapped to ServerErrorException. Being also able to catch
>>>>>>> MessageProcessingException won't help the runtime to decide what
>>>>>>> exactly it can be mapped to (400 or 500), so more enhancements will
>>>>>>> be needed (MessageReadProcessingException,
>>>>>>> MessageWriteProcessingException ?).
>>>>>>> Additionally, it can happen on the client side on the write...
>>>>>>>
>>>>>>> At th moment it appears that the providers throwing either
>>>>>>> WebApplicationException or IOException is a good way of indicating
>>>>>>> that some kind of message processing exception has occurred with the
>>>>>>> cause exceptions also available
>>>>>>>
>>>>>>> Sergey
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -- Santiago
>>>>>>>>
>>>>>>>>>> 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