cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 10:43:04 GMT
Ugo Cei wrote:
> 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.

         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:


      //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         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message