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.

--
Unico

Reply via email to