On 14/01/13 20:02, Marek Potociar wrote:
>
> On Jan 13, 2013, at 7:01 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 11/01/13 16:57, Marek Potociar wrote:
>>> Hello experts,
>>>
>>> I've just committed my proposal resolving the issue
>>> http://java.net/jira/browse/JAX_RS_SPEC-257.
>>>
>>> Here's the change outline:
>>>
>>> - separate ClientException& MessageProcessingException removed& replaced with common ProcessingException
>>> - added client-side ResponseProcessingException (extends ProcessingException)
>>> - updated client-side javadoc
>>> - fixed API method signatures to not declare runtime exceptions in throws clause, only in javadoc (as perhttp://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#throwstag )
>>>
>>> Please, let me know if you have any comments.
>>
>> How are exceptions to do with the client side write and connect issues are to be represented ?
>
> I was thinking along the lines of my last proposal on the subj. I sent to this mailing list earlier: ProcessingException nesting any IOException or other would be raised. so you need to catch the ResponseProcessingException only if you explicitly want to distinguish between req and resp processing errors.
>
That works; IMHO, while technically it is all very precise, losing
ClientException is a mistake, it is the purity winning over the
practicality IMHO...
We will still unwrap and this is deemed to be OK on the client outbound
path - I really liked ClientException you originally introduced, and we
could've had Request(Processing)Exception extending it in case of
outbound faults instead of unwrapping from the exception common both to
the client & server runtimes;
anyway, I'll just update some code and forget about it
Cheers, Sergey
> Marek
>>
>> Sergey
>>>
>>> Marek
>>
>