On 04/09/12 14:43, Bill Burke 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?
>
Well, the purpose of ex.getMessage() is to get the whatever message a
given exception has for a user, and
'ex.getResponse().readEntity(String.class)' requires doing I/O too;
It is really about getting the consensus on whether "ex.getMessage()" is
equivalent, conceptually, to 'ex.getResponse().readEntity(String.class)'
or not.
Well, may be it should return 'null', to encourage users to actually use
JAX-RS API, when handling exceptions
Sergey
> Bill
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com