On Feb 1, 2013, at 7:10 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>> Hmm..., both A and B are response filters, they are processing some Response, A is first to process it and decides to throw an exception (intentionally) - what I don't quite get is whether it means we have an immediate 500, or, we try to map this A-originated exception and if the mapping was successful, then let B a chance to handle this mapped response, even though A thought it was an exception case...
>>>
>>> I'm sorry if I'm slow :-), but I'm still a bit unclear.
>>
>> If A throws an exception that gets mapped, then both A and B will be invoked on the mapped response. If A throws an exception again, then the exception is going to be propagated to the hosting container.
>>
>> Hope it's crystal clear now,
>
> Definitely is, thanks Marek. The fact that A can be re-entered twice was definitely something I was not getting.
>
> Are we sure it is correct though to allow re-entrance into A and indeed all the response filters before A if A throws the exception intentionally, effectively saying 'I've had enough with processing this current response' ? Not really sure whether it is right or not, I guess it is interesting to imagine a bit the possible pros and cons
The exception mapper that catches that exception will likely produce a different response, so you are re-entering the chain with a new response that will not necessarily follow the same execution path as the original.
-- Santiago