cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Extending error handling
Date Mon, 07 Apr 2003 10:33:36 GMT
on 4/7/03 10:52 AM 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!
> 
> 1) Possibility to define a "hierarchy" of error handlers: pipeline -
> subsitemap - sitemap. The behaviour is expected to be the following: When an
> exception occurs, Cocoon shall check whether a handler has been defined for
> the requested resource's pipeline, that is able to handle this specific
> error. If such a handler does not exist, a handler responsible for the whole
> subsitemap is searched. If it also does not exists, an over-all default
> handler, defined in the root sitemap, would be used.
> Our idea now is to extend the tag <map:pipelines> for being able to contain
> <map:handle-errors> tags and add the above behaviour to the treeprocessor.
> This allows handler's to be defined for the hierarchy levels subsitemap and
> sitemap:
> Sitemap:
> <map:pipelines>
> 	<map:pipeline>
> 		<map:mount src=”subsitemap”/>
> 	</map:pipeline>
> 	...
> 	<map:handle-errors> <!-- default handler for whole system -->
> 		...
> 	</map:handle-errors>
> </map:pipelines>
> Subsitemap:
> <map:pipelines>
> 	<map:pipeline>
> 		...
> 		<map:handle-errors> <!-- handler for pipeline -->
> 			...
> 		</map:handle-errors>
> 	</map:pipeline>
> 	...
> 	<map:handle-errors> <!-- handler for whole subsitemap -->
> 		...
> 	</map:handle-errors>
> </map:pipelines>

Oh, I love it!

> 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.
> 
> Any comments?

I see great value on better error handling capabilities and the approach
is clean and well back compatible.

+1

-- 
Stefano.



Mime
View raw message