You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ju...@basf-it-services.com on 2003/04/10 10:41:00 UTC
Errorhandling for internal requests
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.
Re: Errorhandling for internal requests
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Re: Errorhandling for internal requests
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 }