On Apr 3, 2013, at 8:56 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 02/04/13 22:22, Sergey Beryozkin wrote:
>> Hi
>>
>> ProcessingException docs mention "propagated IO exceptions thrown by
>> entity readers and writers during entity serialization and
>> de-serialization."
>
> Well, "propagated" may mean that the runtime catches IO exceptions if any thrown by the providers and wraps them in ProcessingException - which is possible too - though this will effectively prevent the users from writing IOException exception mappers - and I know there are definitely some IOException exception mappers have been written bby CXF users, so I guess a bit more guidance would help
I guess the confusion comes from the fact that what ProcessingException talks about are mostly client-side use cases (because client API is the place where ProcessingException is explicitly mentioned a lot), as is the case you are referring to. Client side does not have exception mappers. On the server side you need to let the exception mappers see the original entity provider exceptions, of course.
HTH,
Marek
>
> Cheers, Sergey
>
>>
>> When should MBR or MBW throw ProcessingException instead of IOException
>> (except for an empty payload + NoContentException case) ?
>>
>> Thanks, Sergey