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 :-)
Cheers, Sergey