cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Lütkemeier <bluetkeme...@s-und-n.de>
Subject Re: Extending error handling
Date Mon, 07 Apr 2003 10:05:58 GMT
Hi,

> -----Ursprüngliche Nachricht-----
> Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Gesendet: Montag, 7. April 2003 11:17
> An: cocoon-dev@xml.apache.org
> Betreff: Re: Extending error handling
>
>
> Björn Lütkemeier wrote:
>
> >Hi,
> >
> >for a customer we need two extensions to the current error handling in
> >Cocoon. Since we think, that this extensions may be of general
> interest in
> >Cocoon, we'd like to ask what you think about it? Thanks for answers!
> >

<snip/>

>
> >2) Each error handler shall not only regard the type of the occured
> >exception for the decision, whether he is responsible for it, but further
> >properties like error codes etc., that are accessible via
> bean-style methods
> >in the exception object.
> >Our idea for this is to extend the new
> >org.apache.cocoon.selection.ExceptionSelector, so that an error handler
> >definition could look like:
> ><map:selector name="exception"
> >src="org.apache.cocoon.selection.ExceptionSelector">
> >	<exception name=”myexc1” class=”example.MyException1”/>
> >	<exception name=”myexc2” class=”example.MyException2”/>
> ></map:selector>
> >...
> ><map:pipeline>
> >	...
> >	<map:handle-errors>
> >		<map:select type=”exception”>
> >			<map:when test=”type=myexc1,errorCode=10”>
> >				...
> >			</map:when>
> >			<map:when test=”type=myexc2,errorCode=20”>
> >				...
> >			</map:when>
> >		</map:select>
> >	</map:handle-errors>
> ></map:pipeline>
> >In this case the exception classes example.MyException1 and
> >example.MyException2 are expected to have a method
> getErrorCode() which is
> >called via reflection from within the selector.
> >One could also think about allowing more complex expression
> within the test
> >attribute like (type=myexc1 and errorCode>=10 and errorCode<20) etc.
> >
>
> In the above, the "errorCode" is actually what defines the kind of
> error. So instead of writing this in the <map:when>, it would be better
> for it to be written in the configuration of the ExceptionSelector.
>
> We could have a JXPathExceptionSelector which extends Exception selector
> to allow an XPath expression on each <exception> configuration :
> <map:selector name="exception">
> <exception name="type1" class="example.MyException1"
> test="errorCode = 10"/>
> <exception name="type2" class="example.MyException1" test="errorCode =
> 10 and contains(errorMsg, 'bad user')"/>
> </map:selector>
>
> Thoughts ?

Good idea. Actually you are right, that the errorCode and perhaps further
conditions define the kind of error and therefore could be written in the
configuration. I think such a solution is suitable for our and other user's
needs. Still have to discuss it with the customer ;-)

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

Björn


Mime
View raw message