cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From juergen.se...@basf-it-services.com
Subject Re: Errorhandling for internal requests
Date Thu, 10 Apr 2003 10:56:29 GMT

Hi Sylvain,

our problem was, that not the error handler itself should decide if it is
responsible for external, internal or always,
but the caller of the resource must do it.
In our opinion the distinction only makes sense for redirects and for
example not for generators (Please see our examples)

Björn and Jürgen






                                                                                         
                                                   
                      Sylvain Wallez                                                     
                                                   
                      <sylvain.wallez@anywar         An:      cocoon-dev@xml.apache.org
                                                     
                      e-tech.com>                    Kopie:   (Blindkopie: Juergen Seitz/BASF-AG/BASF)
                                      
                                                     Thema:   Re: Errorhandling for internal
requests                                        
                      10.04.2003 11:37                                                   
                                                   
                      Bitte antworten an                                                 
                                                   
                      cocoon-dev                                                         
                                                   
                                                                                         
                                                   
                                                                                         
                                                   




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