Bill, Sergey,
would you be able to work together on providing a concrete proposal for a JAX-RS exception hierarchy to start with? IT
should cover both, client as well as server side. The goal would be to reuse the existing exceptions as much as possible
as well as make the exception hierarchy common (for client and server), wherever it is practical.
Let us know,
Marek
On 02/01/2012 03:46 PM, Bill Burke wrote:
>
>
> 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
>