cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT]: InputModules interfaces
Date Tue, 08 Oct 2002 08:26:41 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>>So, summarizing this, it seems that we agree on changing the InputModule
>>>interface to
>>>  Object getAttribute( String name, Map objectModel ) throws
>>>  Iterator getAttributeNames( Map objectModel ) throws
>>>  Object[] getAttributeValues( String name, Map objectModel ) throws
>>>Everyone happy with this?
>>It looks simpler.
>>But why throwing a ProcessingException ? Simply throwing Exception would
>>avoid exception cascading (I hate these never ending stacktraces) and
>>better cope with the variety of implementations.
>Valid the question is: where do you want to handle the

Back to the exception handling stragegy ;-)

AFAIK, exceptions are handled in Cocoon in two places : in 
<map:handle-errors> and in CocoonServlet. As discussed recently, 
everywhere else they should just be propagated. And propagating means 
cascading if the exception you catch doesn't match one of the exception 
types you're declaring to throw.

Now what is the semantic added value of "ProcessingException" compared 
to "Exception" ? The javadoc states "This exception is thrown every time 
there is a problem in processing a request". And Cocoon does nothing 
else than processing a request !

So ProcessingException doesn't IMHO bring much more information than a 
standard Exception. The only added value is that ProcessingException 
_should_ be an indication of where the problem occured, and in that case 
its use should be reserved to pipeline-related classes. If you look at 
Pipeline and Generator, they do throw a ProcessingException. Action does 
not and throws an Exception.

All this to say that I don't like much this ProcessingException that 
doesn't say much and often forces cascading :-)

>If you throw just Exception than the calling code has to test, if the
>thrown Exception is a wrapping or non-wrapping exception if it catches
>the exception. This results in rather ugly code with several catch
>If you throw ProcessingException than the component has to do this
>conversion - personally I like this approach more.
>But if you want, we can "change" this to just Exception.

Yes, please ;-)


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message