On Wed, Jul 10, 2002 at 03:32:42PM +0200, Nicola Ken Barozzi wrote: > > 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 ;) > > And because it isn't strictly needed ;-) > > >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. > > no, you would have a <handle-errors>, we decided that type="" would be > deprecated, since it's redundant. > > >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. > > There are many other attributes, not only getType. > I wrongly assumed that it would be a "level" of error. > We should start giving it a real meaning. > > >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). > > Not really true... > > > 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> > > This I like better... > It basically means that you make the mapping of the exception name to an > easy handle... > > >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 ? > > I would rewrite your case like this: > > <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> > > <map:handle-errors> > > <map:match type="error" pattern="access-denied"> > <map:transform src="accessDenied.xsl"/> > <map:serialize/> > <map:match> > > <map:match type="error" pattern="my-error-case"> > <map:transform src="SpecificError2html.xsl"/> > <map:serialize status-code="500"/> > <map:match> > > <map:match pattern="*"> > <map:serialize status-code="500"/> > <map:match> > > </map:handle-errors> > > But we could simply do: > > <map:handle-errors> > > <map:match type="error" pattern="access-denied"> > <map:transform src="accessDenied.xsl"/> > <map:serialize/> > <map:match> > > <map:match type="exception" pattern="my.app.someSpecificException"> > <map:transform src="SpecificError2html.xsl"/> > <map:serialize status-code="500"/> > <map:match> > > <map:match pattern="*"> > <map:serialize status-code="500"/> > <map:match> > > </map:handle-errors>
Matching for exception types within the handle-errors block - This I like! Because (can I start a sentence with "beacuse"?..hmm) the whole point is to make sure that exceptions can be easly and intuitively handled depending on error type. Regards Michael Melhem > > > Of course, we will need to put a > > <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> > > thing in cocoon.xconf to handle the major types of errors, so that the > match type="exception" is not used a lot, or even at all. > > Other thoughts? > > Keep calm Stefano, I know you get nervous when Sylvain and I discuss at > this speed, but believe me, we are communicating, it's not noise ;-P > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
