On Wed, Jul 10, 2002 at 02:43:37PM +0200, Sylvain Wallez wrote: > Michael Melhem wrote: > > >Dear Cocoon community, > > > >It seems to me that pipelines can only handle two error cases: Namely > >error 500 (General Exception) and error 404 (ResourceNotFoundException). > > > >There appears to be no way currently to handle specific errors that might > >be thrown by pipeline components other than to render a general Error 500 > >page. Am I mistaken? > > > >For example, it may be the case that a custom built generator could throw > >custom Exceptions that a developer would like to handle in a specific > >fashion. > > > >To that end, I propose that pipeline be extendend so that it they can > >handle X number of errors depending on the amount of <map:handle-errors> > >defined in the sitemap for that pipeline. > > > ><sitemap> > > ... > > > > <map:handle-errors type="500"> > > <map:transform src="stylesheets/error2html.xsl"/> > > <map:serialize/> > > </map:handle-errors> > > > > <map:handle-errors type="404"> > > <map:transform src="stylesheets/error2html.xsl"/> > > <map:serialize /> > > </map:handle-errors> > > > > <!-- one more or extra error-handles --> > > <map:handle-errors type="someSpecificException"> > > <-- "type" here could me some sort of short code or the actual > > full name of the Exception class? --> > > <map:transform src="stylesheets/SpecificError2html.xsl"/> > > <map:serialize status-code="500"/> > > </map:handle-errors> > > > > etc.. > ></sitemap> > > > >Does anyone see any problems with this approach? Comments? > > > > > > I like this, and proposed something similar back in december (see > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2) > > It didn't had much acceptance at that time both because it involved > class names in the pipelines and because Nicola Ken was refactoring > error notification ;) > > But I still would like to have something like this, as I think having to > write a <handle-errors type="500"> and then using a <map:select> to > select depending on the error type is counter-intuitive.
I agree, IMHO introducing selectors within an handle-error block (even though this is apperantly possible) will only serve to convolute the situation making the sitemap harder to read and extend. What could be simpler (and more logical) than having an handle-error block for each type? Especially considering that each error-handler already has the type attribute. > > When an exception occurs, the sitemap engine builds a Notifying object > that is available within the <handle-errors>. This Notifying has a > getType() method which is exactly what we need for this "type" attribute. > > But getType() always returns "error" unless your exception implements > Notifying (which none does, and IMO having an exception implement > Notifying to drive sitemap error-handling is mixing concerns). So we > could configure the NotifyingBuilder so that it can associate exception > classes to notifying types. > > <notifying-builder> > <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/> > <type name="500" src="org.apache.cocoon.ProcessingException"/> > <type name="access-denied" src="java.lang.SecurityException"/> > <type name="my-error-case" src="my.app.someSpecificException"/> > </notifying-builder> > > Notice the two first lines that ensure compatibility with what we have > today. > > And then in the pipelines : > <map:handle-errors type="access-denied"> > <map:transform src="accessDenied.xsl"/> > <map:serialize/> > </map:handle-errors> > > <map:handle-errors type="my-error-case"> > <map:transform src="SpecificError2html.xsl"/> > <map:serialize status-code="500"/> > </map:handle-errors> > > Thoughts ? Even independent of implementation detail, I like the idea of having seperate error-handlers for seperate error types. what are the objections to this idea? Regards, Michael Melhem > > Sylvain > > -- > Sylvain Wallez > Anyware Technologies Apache Cocoon > http://www.anyware-tech.com mailto:[EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
