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?
>
> 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? How about approaching this also with a small set of more specific
child exceptions?
Marek
>
> Sergey