On Sep 4, 2012, at 3:43 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 9/4/2012 9:31 AM, Sergey Beryozkin wrote:
>> On 04/09/12 14:24, Bill Burke wrote:
>>>
>>>
>>> On 9/4/2012 8:30 AM, Sergey Beryozkin wrote:
>>>> Hi
>>>>
>>>> Suppose we have a server returning 500 and also choosing to add some
>>>> text in the response body.
>>>>
>>>> We can write:
>>>>
>>>> catch (ServerErrorException ex) {
>>>>
>>>> String errorMessage = ex.getResponse().readEntity(String.class);
>>>>
>>>> }
>>>>
>>>> Would it make sense to request that
>>>>
>>>> ex.getMessage() is equivalent to
>>>> ex.getResponse().readEntity(String.class);
>>>>
>>>> ?
>>>>
>>>> Cheers, Sergey
>>>
>>> I would say no.
>>>
>> Did you forget to say 'why' :-) ?
>>
>> Returning 'null' for ex.getMessage() is not a big issue, but in the
>> context of the client processing the server exception response
>>
>> ex.getMessage() == null
>> ex.getResponse().readEntity(String.class) != null
>>
>> does not seem consistent. To me,
>> "ex.getResponse().readEntity(String.class)" is an exception message too.
>>
>> Just a thought really,
>>
>
> Because you'd have to do I/O to read the message and log it?
While I'm still not sure I like the Sergey's idea (which is still interesting and I'd like to see other EG members to chime in), can't you just override the exception getMessage() method to do the I/O lazily?
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com