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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com