I do wonder sometimes whether IDEs ought to be withheld from programmers for a couple of weeks a year just to remind them to think — self included.
That sounds rather harsher than I mean to be; sorry. The root cause is that I spent a good few minutes today reducing an (admittedly already overlarge) JUnit test case by a substantial percentage thanks to this little idiom:
try {
couldThrowCheckedException();
} catch(Exception e) {
fail("Exception thrown");
}
I think the forces, right or wrong, operating in the minds of coders when they write this are as follows:
- checked exceptions are a nuisance, they hinder your smooth progress through code (I know, I know), and they’re not what you’re interested in because this is a positive test-case, right?
- Eclipse helpfully offers to surround the exception-throwing call with a try/catch block. How handy! It also offers (I think as the first option) to add a throws clause, but no one seems to choose that. It’s the path of least resistance, so let’s do that and worry about it later.
- They’re not consistently looking at the output of their JUnit (perhaps they’ve been hypnotised by the green bar) — if they had to rely on the text output, they’d be frustrated by the loss of that juicy stacktrace in e.
- They’re not writing the parallel failure cases. If they were, they’d have had an interest in the exception and might have chosen to do differently in the success case.
- The difference between failure and error is not well-understood. In one sense I sympathise (not green == bad), but the distinction between failure and error is an important one — an error may mean you don’t understand your application or the use of a library it depends on as well as you think you do; a good failure (in development, I mean) means your suspicions were right and it could go wrong like that: in other words, it affirmed your understanding rather than contradicting it.
I’d be interested to see whether TDD made a difference to these forces; I know it did for me, and made a huge and fairly immediate difference to all aspects of my code (mostly, I have to say, quality; but also simplicity). TDD draws the coder into the code; you can’t just write to a spec and be done with it. I would hope that it also draws coders into a more rewarding coding cycle; they get to write more code, they get to really understand what’s going on, the tests document the system in a way which makes sense to them, and they get to creatively challenge the design.
Cue Eliza Doolittle singing Wouldn’t it be lovely …
