On 2/1/12 9:40 AM, Santiago Pericas-Geertsen wrote:
>
> 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?
>
Exception hierarchy is nice, IMO. Especially on the client side.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com