cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <u....@cbim.it>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 08:29:15 GMT
Nicola Ken Barozzi wrote:
> Ugo Cei wrote:
>> We have something worse than generic ProcessingExceptions being 
>> thrown, we have components throwing CascadingException. Which not only 
>> force clients to check them, but create an unnecessary dependence on 
>> Avalon.
> 
> Whaich I agree with, but still it's not about checked VS unchecked.

It's a different issue, yes. I mentioned it just because I noticed that 
it should be fixed while reparenting ProcessingException.

It would be better if CascadingException were abstract, and 
ProcessingException too, so that throwers would be forced to reuse or 
define a more specific exception class, instead of being lazy.

For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can count 
on exception chaining) I will propose to define a Cocoon-specific 
hierarchy of exceptions, whose root is java.lang.RuntimeException. And 
3rd party exception classes like SAXException will have to be wrapped 
inside Cocoon-specific runtime exceptions.

This is the approach taken by Spring, and I know that many of you don't 
like it, but ideas change with time, and we will have plenty of time to 
discuss and change the minds of people. Even mine, maybe ;-).

>> And I'm not going to throw out any baby. I'm going to throw out lots 
>> of totally useless "catch" clauses that do nothing but litter the code.
> 
> You don't need to use unchecked exceptions to do that. I don't see the 
> connection.

How about this?

   } catch (ProcessingException e) {
     getLogger().debug("Rethrowing exception", e);
     throw new SAXException(e);
   }

This is not only useless, it's plain wrong.

	Ugo



Mime
View raw message