users@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Mon, 20 Feb 2012 14:22:32 -0500

On 2/20/12 8:36 AM, Sergey Beryozkin wrote:
> Hi Bill,
> On 20/02/12 13:26, Bill Burke wrote:
>> 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
>> }
>>
>
> That was actually the point I was trying to highlight in my previous
> response to Marek, but in a different light :-)
>
> Basically, NotFoundException is a 'beautified' representation of 404 and
> your example looks fine, but to be honest I do not expect users doing
> NotFoundException catches *alongside* with checking the response types
> for all the other possible HTTP errors, it does not make sense to me at
> least. The above will actually look like exactly like the one you types
> below with an extra NotFoundException block added in but with one less
> switch check for 404,
>


Sergey, IMO, this is the same argument for or against Spring JDBC. With
Spring JDBC, they have an exception hierarchy for most/all JDBC error
codes so that you can catch the appropriate exception.

In Rest at least there are many cases in client code where you want to
explicity catch and handle a specific error code. 404 being the most
common especially with database driven RESTful resources.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com