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:
i.e.
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com