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.
Ugo
