[jax-rs-spec users] [jsr339-experts] Re: Re: Exceptions for representing HTTP errors

From: Bill Burke <>
Date: Thu, 17 May 2012 10:27:09 -0400

On 5/16/12 7:57 AM, Sergey Beryozkin wrote:
>> try {
>> String response = target.request("text/plain").get(String.class);
>> ...
>> } catch (RedirectionException ex) {
>> // ok, seems I have a wrong link, let's try the correct link, if
>> available
>> } catch (ClientErrorException ex) {
>> // i sent a wrong request, let's try to fix it and resend
>> } catch (ServerErrorException ex) {
>> // uups, there's nothing i can do about it
>> }
>> The above seems to make sense in theory, but I admit I am not sure if
>> it would work well in practice. Perhaps a flat structure with
>> exceptions dedicated to specific error codes is enough in the end.
> I think that might not be ideal when the writing the end-user (device)
> code against say OAuth authorization servers, where the redirect is part
> of the overall solution. IMHO the redirect is not a fault, it is the
> server guiding the client to the appropriate resource. It might be
> treated as the fault but it will not be the right approach for all the
> redirects. May be we can get a new thread for discussing how the client
> should react to redirects, is it an exception or a null return (in case
> of typed responses), etc

IMO, you *have* to have redirect exceptions for the case of clients
invocations that don't return a Response. Automatic redirection should
not be default behavior as it can be perceived as a security risk.

IMO, there is no harm in having a family superclass. I would expect
that most code would look like this:

try {
   String response = target.request("text/plain").get(String.class);
} catch (RedirectException ex) {
   // decide whether to redirect
} catch (ServiceUnavailableException ex) {
   // check for Retry-After header and retry again
} catch (WhateverTheRootExceptionIs failure) {
   // we failed log the failure

Also, might also be nice to have a static from(Response) method that
converts a Response to the approriate exception:


Response response = target.request().get();
if (!res.getStatus() == OK) {
    throw WhateverRootExceptionIs.from(response);

>> In any case, what I am still missing in the solution is a proposal how
>> to handle cases when application code throws directly a WAE with a
>> code covered by a specific exception. Seems to me that for the
>> exception mappers and client side to work correctly, we need to catch
>> these and re-throw as the correct sub-type. Right?

I thought the root class was going to be WAE?


Bill Burke
JBoss, a division of Red Hat