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
