On May 17, 2012, at 4:27 PM, Bill Burke wrote:
>
>
> 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
> }
As I mentioned earlier, I tend to agree.
>
> 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);
> }
So, IIUC, you would place the method on WebApplicationException? I like the idea.
>
>
>>> 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?
That's my understanding too.
Marek
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com