cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Wed, 10 Jul 2002 13:32:42 GMT

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>


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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message