On 20/02/12 19:22, Bill Burke wrote:
>
>
> 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.
>
Sounds good...well, I think we should agree on the base classes such
finer grained exceptions would derive from; WebApplicationException
seems the good candidate.
Similarly, finer grained exceptions can be derived from the base
ClientException (updated as proposed in the other email), example,
ConnectionNotEstablished, etc...
Sergey