cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: Errorhandling for internal requests
Date Thu, 10 Apr 2003 13:14:59 GMT
Sylvain Wallez wrote:

> juergen.seitz@basf-it-services.com wrote:
>
>> Hi,
>>
>> we noticed the following fact concerning the treeprocessor: In case 
>> of an
>> internal request, the error handler defined for a pipeline is explicitly
>> NOT called to handle an exception, but the exception is simply 
>> thrown. Now
>> lets consider two scenarios:
>>
>> 1)
>> <map:pipeline>
>>             <map:match pattern="test1">
>>                         ...
>>             </map:match>
>>             <map:handle-errors> <!-- handler 1 -->
>>                         <map:select type="exception">...</map:select>
>>             </map:handle-errors>
>> </map:pipeline>
>> <map:pipeline>
>>             <map:match pattern="test2">
>>                         <map:generate src="cocoon://test1"/>
>>                         ...
>>             </map:match>
>>             <map:handle-errors> <!-- handler 2 -->
>>                         <map:select type="exception">...</map:select>
>>             </map:handle-errors>
>> </map:pipeline>
>> In this case it is of cause reasonable NOT to call handler 1 if test1
>> causes an exception, 
>

Is it? It highly depends on your application. In many cases it would be 
useful to call handler.
<snip/>


>> 2)
>> <map:pipeline>
>>             <map:match pattern="test1">
>>                         ...
>>             </map:match>
>>             <map:handle-errors> <!-- handler 1 -->
>>                         <map:select type="exception">...</map:select>
>>             </map:handle-errors>
>> </map:pipeline>
>> <map:pipeline>
>>             <map:match pattern="test2">
>>                         <map:redirect-to uri="cocoon://test1"/>
>>             </map:match>
>>             <map:handle-errors> <!-- handler 2 -->
>>                         <map:select type="exception">...</map:select>
>>             </map:handle-errors>
>> </map:pipeline>
>> In this case however it may be completely unsuitable, that handler 1 
>> is not
>> called. In our opinion by performing the redirect test2 is no longer
>> responsible for what happens. 
>

Actually, name of element here - redirect-to - is misleading. Because 
what is happens (with cocoon:// uri) is forward, not redirect. Hence 
handler 2 is still responsible.
<snip/>


>> To solve this problem we propose to add a new boolean attribute
>> "handle-errors" to the <redirect-to>-tag.
>

I would suggest not to go this way.

My preference would be to always call the error handler 1 from the 
examples above. Then, if you don't want this handler processing your 
error, then simply remove this handler. If you want - then simply leave 
it there. If you sometimes want this handler, and sometimes don't want - 
create two different pipelines:

<map:pipeline internal-only="true"> <!-- INTERNAL! -->
            <map:match pattern="test0">
                        ...
            </map:match>
            <!-- No handler! -->
</map:pipeline>
<map:pipeline> <!-- same as test0, with handler -->
            <map:match pattern="test1">
                        <map:redirect-to uri="cocoon://test0"/>
            </map:match>
            <map:handle-errors> <!-- handler 1 -->
                        <map:select type="exception">...</map:select>
            </map:handle-errors>
</map:pipeline>
<map:pipeline>
            <map:match pattern="test2a"> <!-- handler 1 is called -->
                        <map:generate src="cocoon://test1"/>
                        ...
            </map:match>
            <map:match pattern="test2b"> <!-- handler 2 is called -->
                        <map:generate src="cocoon://test0"/>
                        ...
            </map:match>
            <map:handle-errors> <!-- handler 2 -->
                        <map:select type="exception">...</map:select>
            </map:handle-errors>
</map:pipeline>

<snip/>


>> Any comments?
>
>
> I had some thoughts about this while refactoring error handling, and 
> my feeling is that what this flag should be better located on the 
> <map:error-handler>, since this is where you know if the pipeline 
> should provide an error page in case of failure (case of coplets for 
> example) or propagate the exception.
>
> This would then become <map:handle-errors when="always">, with 
> possible values for "when" being "external", "internal", "always". The 
> default being "external", since it is the current behaviour. 


 From my POV, this would be second best choice (first I outlined above).

Vadim



Mime
View raw message