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)?
-- 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.
>>>>
>>>>
>>
>>