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
Sergey
>
>
> 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.
>>>
>>>
>
>