users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Concerns about the client-side exception hierarchy

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 1 Feb 2012 09:40:09 -0500

On Feb 1, 2012, at 9:15 AM, Bill Burke wrote:

>
>
> On 2/1/12 9:11 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Jan 30, 2012, at 5:48 PM, Sergey Beryozkin wrote:
>>
>>>> MethodNotAllowedException
>>>> BadRequestException
>>>> NotAcceptableException
>>>> InternalServerErrorException
>>>> UnauthorizedException
>>>> UnsupportedMediaTypeException
>>>> NotFoundException
>>>>
>>>>
>>>> Finally, these above exceptions would be useful on the server side.
>>>> *NOT* for application code to catch, but rather to write
>>>> ExceptionMappers for. So, Jersey/Resteasy whoever would throw those
>>>> exceptions internally, and applications could write ExceptionMapper for
>>>> those exceptions.
>>>>
>>>> Resteasy implemented these features on client/server after suggestions
>>>> from users.
>>
>> I'm not sure I follow this. So the framework throws and catches the
>> exception in order to call the user-defined mapper? Can you elaborate?
>> This seems odd
>>
>
> I've had the case where users want to handle 404, 405, etc. on their own instead of the JAX-RS container handling them automatically. This is especially the case where users want to send specific error formats back to the client. That make sense more?
>
> Also, these exceptions might be thrown on the server side by app code too.

 I understand. In fact, the spec states that implementations should generate a WebApplicationException with the appropriate status code in all those cases (Section 3.7). So the use case should already be covered, but it's not as convenient as having an exception hierarchy?

-- Santiago