Let me show you the benefits of an exception hierarchy on client and server:
This code is much better:
try {
Client c = ...;
String result =
c.target("
http://.../resource/1").request().get(String.class);
} catch (NotFoundException ex) {
// handle it
} catch (Exception ex) {
// all the rest
}
Than what we would currently have to do:
try {
...
} catch (InvocationException ie) {
switch(ie.getResponse.getStatus()) {
case 404:
// handle it
break;
case XXX:
// handle it
break;
default:
break;
}
On the server side, the advantage is less obvious, but people can write
their own ExceptionMappers for specific exceptions rather than doing a
similar switch statement in one base exception mapper. Also, code
becomes more readable:
@GET
public String get(@PathParam("id") id) {
if (!exists(id)) {
throw new NotFoundException();
// or throw new NotFoundException("text/plain", "Entity not found);
}
On 2/18/12 6:41 AM, Marek Potociar wrote:
>
>
> On 02/17/2012 04:55 PM, Sergey Beryozkin wrote:
>> Hi Marek,
>>
>> On 17/02/12 11:38, Marek Potociar wrote:
>>> 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.
>>>
>>
>> I think what you suggest is rather different to what I had in mind when starting the thread in the first place. I'd be
>> happy to work with Bill :-), but at the moment I'd prefer us focusing on a much smaller task, i.e, on making sure the
>> client code can get some reasonable support for figuring out:
>> - where the exception has occurred (client or server side)
>
> That's obvious from the response status code (if response is available), isn't it?
>
>> - more information about the server side exception
>
> Are you suggesting to standardize content of the responses with HTTP status code>= 400 ?
>
>>
>> To that end I've typed some comments, particularly I proposed introducing ClientWebAplicationException and
>> ServerWebApplicationException and work with these classes to make them useful.
>>
>> That is the base support, what do you think about that.
>>
>> As far as a finer grained hierarchy is concerned...
>> For now I'm not quite in favor of it.
>>
>> I can see why writing an ExceptionMapper<NotAcceptableException> is simpler than a custom
>> ExceptionMapper<WebApplicationException> and checking the status but I'm not convinced it can offer a complete 'cover'
>> for a user, instead of getting a single base ExceptionMapper<WebApplicationException> one would need to register
>> 5-7-maybe more mappers to cover all the possible HTTP errors the runtime may react to.
>
> Without any comments about fine vs. coarse gained exception hierarchies, what makes you think that one would NEED TO
> provide exception mappers for all exception types and not just one mapper for the base exception type?
>
>>
>> Exactly the same on the client side. With the finer grained hierarchy one would need to have a fairly big sequence of
>> catch blocks, with every individual exception basically offering an 'easy' interpretation of the HTTP error code.
>
> Again, why not just a single catch block for the base exception type? Additionally, since we would stick to extending
> from RuntimeException, there would be no mandatory catch block at all.
>
>>
>> I can't say I'm against the finer-grained hierarchy, rather I'm a bit cautious about introducing it at this stage, may
>> be for 2.1...
>
> I see. I guess what I am looking for is a concrete proposal with proper javadoc describing the exception hierarchy, that
> is potentially extensible and commonly reusable on server and client side. I did not try to imply the exception
> hierarchy proposal you come up with must be fine-grained. I'd leave that to your consideration and subsequent EG discussion.
>
>>
>> We'd have something like this for a start:
>>
>> BaseException (WebApplicationException ?)
>> | |
>> | |
>> ClientWebApplicationException ServerWebApplicationException (both: the client side)
>>
>> for a start.
>
> My initial feedback to those names would be that "client web application" sounds like an oxymoron and "server web
> application" sounds like a redundant definition. ;-)
>
>>
>> Possibly at the next stage, we can start with introducing some new finer exceptions directly off the BaseException and
>> get them reusable on both sides
>
> Ok, as I said, I am looking for a concrete, javadoc-ed proposal. The above is a good start for an internal conversation,
> but too fuzzy for including in the API yet.
>
> Marek
>
>>
>> Thanks, Sergey
>>
>>> 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
>>>>
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com