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