cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Errorhandling for internal requests
Date Thu, 10 Apr 2003 09:37:58 GMT
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, 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?
>

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.

Thoughts ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message