On Aug 24, 2012, at 10:29 AM, Marek Potociar wrote:
>>>
>>> On 8/23/2012 10:33 AM, Marek Potociar wrote:
>>>> Btw. I'm starting to think that perhaps we should really leave things as
>>>> they are specified now, just clarify the processing of a mapped
>>>> exceptions. IOW:
>>>>
>>>> * an exception is mapped only once per a single request-response
>>>> processing cycle (to prevent exception mapping loops)
>>>> * any exception thrown while processing a response created as a result
>>>> of previous exception mapping is treated as "unmapped", i.e. it is
>>>> propagated to the hosting IO container
>>>> * a response created from a mapped exception is run through the
>>>> response filter chain that is constructed based on a given
>>>> processing context. I.e. if a resource has been matched, then all
>>>> response filters applicable to the resource would be invoked; if a
>>>> resource has not been matched yet, only global response filters
>>>> would be invoked.
>>>>
>>>>
>>>> The above would ensure that all exceptions - from resources as well as
>>>> from providers - are treated consistently. Any subsequent exceptions
>>>> would be then treated consistently too.
>>>>
>>>
>>> At the moment, I don't see any problems with the above. Good work Marek.
>>
>> I don't have a problem with this approach either. I thought there were concerns about "going back" in the processing chain (e.g., re-running the response filter chain after an exception is thrown in a response filter) and the potential for loops. Of course, as long as we state that an exception is mapped only once, this is taken care of.
>
> From my understanding of the text, the spec already says that (prohibits exception mapping loops). We just need to clarify that a mapped exception is run through a response filter chain (where the response filter chain is assembled based on the actual request processing context).
>
>>
>> I'll double check and make sure the spec is crystal clear about this.
>
> Thank you,
Updated text to make this more clear.
-- Santiago