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
Sergey
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com