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