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.
Gaaak! Why so? I just don't get it, you don't like wrapping but are going to do it nevertheless?
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.
First of all, why are you logging? Useless. Second, why are you rethrowing the exception? There is a meaning to it.
try{
here the IO makes an error; } catch (ProcessingException e) {
//a ProcessingException occurred.
//what can I do about it? should I retry?
//I was not able to process something, but
//now I have to honor my contract.
//Can I end the xml? Yes... so let's do it:end.the.xml();
//I'm not throwing, as for SAX I'm ok, the SAX stream is ok
//throw new SAXException(e);
}IOW, the fact that there is an exception mismatch between what I catch and what I throw should make me think about what impact the caught exception has on me and on the possibility or not of finishing the work. If I cannot finish what I can do - and note that the exceptions I throw define what my parent can or cannot fix - shall I eventually tell my parent.
If you use Runtime exceptions all this goes away and instead of rethrowing you will see exceptions being gobbled up.
Not only we will have the opposite problem, ie not catching instead of rethrowing everything, but we will be unable to go through the code searching for rethrowing and asking ourselves if it's correct or not.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------