Hi Sergey,
Obviously, I did not give it enough thought. What you're writing makes a lot of sense. So I'm changing my cautious "0/+1" to clear "-1" on the suggested improvement.
Marek
On Nov 2, 2012, at 11:58 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 02/11/12 10:47, Marek Potociar wrote:
>> Hello experts,
>>
>> For full context, please check out the proposal from Bill Burke:
>> http://java.net/jira/browse/JAX_RS_SPEC-257
>>
>> While I still need to think about this a little bit more, off the top of
>> my head it seems like an interesting idea to me: We may perhaps be able
>> to consolidate the ClientException and MessageProcessingException to a
>> single ProcessingException that would be used on both, client and
>> server, not only in case of filter/interceptor failures but also in all
>> cases where ClientException has been used before (any client errors).
>>
>
> I really like the current approach where ClientException represents all the errors which happened at the client side, where MessageProcessingException acts as a cause exception (ClientException.getCauseException()) in case of read/input processing errors.
>
> Having MessageProcessingException representing a client send error on the client side would also be confusing IMHO.
>
> On the server side, MessageProcessingException has to be mapped either to 400 or 500, depending on where it has occurred, so to be honest I do not see much benefit in unifying ClientException & MessageProcessingException.
>
>> One reservation I had is that it would be a bit harder to distinguish
>> where did the error came from. But it does not seem to be such a big deal...
>>
>
> I think
> try {
> client.get();
> } catch (ClientException ex) {
> if (ex.getCause() instanceof MessageProcessingException) {
> // read or write error
> } else {
> // connection issue...
> }
> } catch (WebApplicationException ex) {
> // error from the server
> }
>
> Looks OK
>
> Cheers, Sergey
>
>> In any case, I'm looking forward to your feedback.
>>
>> Thanks,
>> Marek
>
>