Strange behaviour of unhandled errors

[ju...@basf-it-services.com]

Hi,

we are currently implementing hierarchy for error handlers on the levels
map:pipelines and map:pipeline (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104970554907551&w=2). We
noticed that the treeprocessor acts in a strange way. Suppose you have the
following sitemap:

<map:pipelines>
             <map:pipeline>
                         <map:match pattern="blah">
                                     <map:generate src="blah.xml"/>
                                     ...
                         </map:match>
                         <map:handle-errors>
                                     <map:select type="exception">
                                                 <map:when test
="exc2">...</map:when>
                                                 <map:when test
="exc3">...</map:when>
                                     </map:select>
                         </map:handle-errors>
             </map:pipeline>
             <map:pipeline>
                         <map:match pattern="*">
                                     <map:generate src="blahblah.xml"/>
                                     ...
                         </map:match>
             </map:pipeline>
             <map:handle-errors>
                         <map:select type="exception">
                                     <map:when test="exc1">...</map:when>
                         </map:select>
             </map:handle-errors>
</map:pipelines>

Now in blah an exception exc1 occurs. The selector in the error handler
does not match to it and therefore the corresponding treeprocessor node
returns "false". This causes the sitemap to react as if no match has been
found and therefore pipeline * is executed later!! This causes an exception
"Generator already set. You can only select one Generator (file)"
Furthermore if pipeline * does not exist, a ResourceNotFoundException would
be thrown, completely obscuring what really happened.
We think that this is a bug and therefore would like to fix it. Furthermore
the second handler (in the hierarchy above) will not be called and handle
exc1, since the treeprocessor does not know  any more that an exception has
occured (That's why we need the fix for the hierarchy ;-) ).
We propose to implement the following behaviour: If an error handler is not
able to handle the error (so the HandleErrorsNode returns "false") the
exception is rethrown instead of simply forwarding the "false" and can then
be handled by other handlers in the hierarchy.

What do you think?

Regards, Björn and Jürgen.