cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From juergen.se...@basf-it-services.com
Subject Errorhandling for internal requests
Date Thu, 10 Apr 2003 08:41:00 GMT
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, since otherwise the generator would not notice, that
an exception has occurred in test2. In fact it would receive data produced
by handler 1, which it may not be able to process. Therefore in the current
implementation resource test1 throws an exception to the generator, that is
then handled by handler 2. So this case is ok, nothing to do :-)

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. If an error occurs in test1 handler 1, who
knows what to do then, should handle it. Handler 2, which is called in the
current implementation, would normally not know anything about the specific
exceptions, that may occur in test1.

To solve this problem we propose to add a new boolean attribute
"handle-errors" to the <redirect-to>-tag. If it is set to "true", the
treeprocessor calls the resource's error handler if an exception occurs, if
it is set to "false", the exception is thrown like today. To ensure
complete backward compatibility the default will be "false".

Any comments?

Regards, Bjoern (bluetkemeier@s-und-n.de)
and J├╝rgen.


Mime
View raw message