Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Strange behaviour of unhandled errors
To: cocoon-dev@xml.apache.org
Message-ID: <OFB75838D4.4D39780E-ONC1256D05.002B44DD@rz-c007-j650.basf-ag.de>
From: juergen.seitz@basf-it-services.com
Date: Fri, 11 Apr 2003 10:34:11 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Hi,

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

<map:pipelines>
             <map:pipeline>
                         <map:match pattern=3D"blah">
                                     <map:generate src=3D"blah.xml"/>
                                     ...
                         </map:match>
                         <map:handle-errors>
                                     <map:select type=3D"exception">
                                                 <map:when test
=3D"exc2">...</map:when>
                                                 <map:when test
=3D"exc3">...</map:when>
                                     </map:select>
                         </map:handle-errors>
             </map:pipeline>
             <map:pipeline>
                         <map:match pattern=3D"*">
                                     <map:generate src=3D"blahblah.xml"=
/>
                                     ...
                         </map:match>
             </map:pipeline>
             <map:handle-errors>
                         <map:select type=3D"exception">
                                     <map:when test=3D"exc1">...</map:w=
hen>
                         </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 be=
en
found and therefore pipeline * is executed later!! This causes an excep=
tion
"Generator already set. You can only select one Generator (file)"
Furthermore if pipeline * does not exist, a ResourceNotFoundException w=
ould
be thrown, completely obscuring what really happened.
We think that this is a bug and therefore would like to fix it. Further=
more
the second handler (in the hierarchy above) will not be called and hand=
le
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=F6rn and J=FCrgen.=