cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 15:03:09 GMT
Nicola Ken Barozzi wrote:
> You are forced by a contract, just as you are forced by other types.

Personally, I don't buy this "design by contract" thing, I much prefer 
"design by testing", or "Test Driven Design", if you prefer :-).

> He should blame the fact that he does not have ProcessingException in 
> *it's* throws cause even if he cannot cope with it.

Since he's implementing an interface that doesn't declare it in its 
"throws" clause, he has no choice.

> I never remove code smell. If it works, don't touch it, even if it 
> smells. If it doesn't work, fix it. Code beauty and lack of odor only 
> creates nice empty boxes, and I know something about it unfortunately.

I see we have widely divergent opinions on this. I believe that code 
rots unless you continuously refactor it. I believe that you should fix 
broken windows, even if you live in Barbados, before the whole house 
starts crumbling down.

>> If you don't agree, then what is your proposal?
>    catch (ProcessingException e) {
>      //see if I *really* need to rethrow it
>      throw new *Exception(*, e);
>    }

Do you plan to go over our codebase and, for every such case, evaluate 
if we *really* need to rethrow it?

> Get it right with 2.2 by defining the contract with the container, IE 
> what the component.

Hmmm, maybe you truncated the sentence a little too early here: "what 
the component ..."?

Anyway, my take on this is that trying to enumerate in a contract 
everything that might possibly go wrong is impossible. But, as I said, 
we have plenty of time to discuss this before 2.2. This call for votes 
is for 2.1.

> Since you know that we have dozens of places in the code with this 
> thing, do you care posting a dozen of them here?

OK, stay tuned.


View raw message