Hi,
It's an interesting idea, yet I'm not sure I see the advantage.
Here's what you should be able to do (eventually) without an exception being thrown regardless of the response status code:
// does not throw WebApplicationException if status is not 2xx
Response res = target.request(MediaType.APPLICATION_JSON).get();
String content = res.readEntity(String.class);
Or, if you don't care about status codes:
// does not throw WebApplicationException if status is not 2xx
String content = target.request(MediaType.APPLICATION_JSON).get().readEntity(String.class);
as opposed to:
// throws WebApplicationException if status is not 2xx
String content = target.request(MediaType.APPLICATION_JSON).get(String.class);
Alternatively, you can use the same-root exception hierarchy we plan to introduce to process exceptional response status codes:
String content;
try {
content = target.request(MediaType.APPLICATION_JSON).get(String.class);
} catch (WebApplicationException ex) {
// process all error status codes
}
or more fine-grained, e.g.:
String content;
try {
content = target.request(MediaType.APPLICATION_JSON).get(String.class);
} catch (RedirectionException ex) {
// Process 3xx errors (with a support for redirect on the exception)
} catch (ClientErrorException ex) {
// Process 4xx errors
} catch (ServerErrorException ex) {
// Process 5xx errors
}
I agree that the proposal is more verbose compared to your suggestion. But it is IMO also more universal and simpler to specify and use.
Marek
On Jun 14, 2012, at 2:34 PM, Luis Gervaso wrote:
> Hi,
>
> Thanks, I understand.
>
> Let me explain my use case:
>
> From client i tried to invoke a operation and a server fault is returned. For example this can be an HTTP 500 Internal Server Exception.
> In the payload i have JSON/XML i want to parse in order to get more info on the client side about the exception and convert it to a client
> known exception, for example: ClientKnownException("Detailed message from JSON payload")
>
> I think it can be done for example
>
> target.request(MediaType.APPLICATION_JSON).expectedException(ClientKnownException, 500, 503).get()
>
> where
>
> exepectedException(Throwable t, int... codes) {
>
> }
>
> Luis
>
> On Thu, Jun 14, 2012 at 12:03 AM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
> Hi,
>
> we are currently working in the JAX-RS expert group on revisiting the proposed exception hierarchy. The general idea is something like this:
>
> Client-side exceptions will be wrapped into an InvocationException and rethrown. Invocation exception will not have the Response anymore.
> Server-side error responses will be converted to a subclass of the WebApplicationException only in case the user tries to directly convert the response entity to a Java type, e.g.:
> String content = client.target(...).request().get(String.class) // may throw WAE
>
> This is to make sure users don't confuse error responses for normal ones during response content processing. To avoid the exception in the case #2, a user could access the whole Response instance instead:
>
> Response response = client.target(...).request().get();
> String content = response.readEntity(String.class); // does not throw WAE
>
> In the case above, an exception will not be thrown as it is expected the user can check the response status to make sure the response is not an error.
>
> Alas, the above is not yet implemented in Jersey as well as the problem with the request context is not fixed yet. We should have it fixed in a few weeks.
>
> Stay tuned,
> Marek
>
> On Jun 11, 2012, at 5:15 PM, Luis Gervaso wrote:
>
>> Hi,
>>
>> What is the recommended way to handle InvocationException on the client side?
>>
>> Every Error Response comes to me with an error description in the response entity.
>>
>> 1) If i handle on a filter:
>>
>> throw readEntity(CustomException.class)
>>
>> is wrapped with an InvocationException
>>
>> 2) if i handle on my client
>>
>> I can not perform readEntity since I'm not in a request context
>>
>> Any clues?
>>
>> Regards
>>
>>
>> --
>> -------------------------------------------
>> Luis Alberto Gervaso Martin
>> Woorea Solutions, S.L
>> CEO & CTO
>> mobile: (+34) 627983344
>> luis_at_woorea.es
>>
>
>
>
>
> --
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344
> luis_at_woorea.es
>