cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 12:57:26 GMT
Nicola Ken Barozzi wrote:

> Ugo Cei wrote:
>> Nicola Ken Barozzi wrote:
>>> In any case (and note that this is a vote, not a veto) the main 
>>> reason is that in doing this we risk to throw out the baby with the 
>>> water: I prefer a lot to remove ProcessingExceptions comptely and 
>>> have the Cocoon components throw all the exceptions that the 
>>> container can and will handle. IOW, I don't want to have an implicit 
>>> contract but a more detailed and explicit one. In any case, generic 
>>> ProcessingExceptions are evil, and this is a fact that we have known 
>>> for a long time.
>> 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.
>> 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.
The connection is fairly obvious to me. If you want to throw out the 
useless catch clauses (which really are useless, I don't think you are 
challenging that?) then there are two options. Either declare all 
possible exception types in the method declaration (which in practice 
means declaring throws Exception in the interface) or convert checked 
exceptions to unchecked ones. Since the semantic value of the former is 
nearly nil I personally see that option not adding a lot of value, just 
more clog.

+1 for Ugo's proposal from me.


View raw message