Tuesday, June 19, 2007

Recently, Neal Gafter mused about whether we should consider removing checked exceptions from Java. The motivation from this was not what you might expect, but rather an observation that checked exceptions interacts heavily with a lot of other language features, and that evolving the language might be easier if we were willing to consider removing some features. (Neal knows this won't ever happen, he's just trying to get us thinking about Life After Java.) Not surprisingly, it generated a storm of comments, ranging from "hell yeah!" to "hell no!".

This isn't a new topic; it comes around every few years. A few years back I wrote about the debate surrounding checked exceptions, and the debate continues to rage. My problem is that I think most of the vocal opponents of checked exceptions are objecting for the wrong reasons (back then, I wrote: "My opinion is that, while properly using exceptions certainly has its challenges and that bad examples of exception usage abound, most of the people who agree [ that checked exceptions are a bad idea ] are doing so for the wrong reason, in the same way that a politician who ran on a platform of universal subsidized access to chocolate would get a lot of votes from 10-year-olds").

Reading through the against-checked-exceptions commenters on Neal's blog, we can divide them into three primary groups:

"I don't like checked exceptions because they're too much work."

"Checked exceptions were a nice idea in theory, but using them correctly makes your code really ugly, and I'm left with a choice of ugly code or wrong code, and that seems a bad choice."

"Checked exceptions are a good idea, but the world isn't ready for them." (Frequent refrain from this group: "Man, have you looked at some of the code out there?")

To the people in camp (1), I say: engineering is hard -- get over it. Error handling is one of the hardest things to get right, and one of the easiest things to be lazy about. If you're writing code that's supposed to work more than "most of the time", you're supposed to be spending time thinking about error handling. And, pay for your own damn chocolate.

To the people in camp (2), I have more sympathy. Exceptions do make your code ugly, and proper exception handling can make your code really ugly. This is a shame, because exceptions were intended to reduce the amount of error-handling code that developers have to write. (Ever try to properly close a JDBC Connection, Statement, and ResultSet? It requires three finally blocks. Ugly if you do it right. But, almost no one ever does it right. (The real culprit here is that close() throws an exception -- what are you supposed to do with that exception? But that's fish under the bridge.))

But perhaps there's a way to not throw the baby out with the bathwater, by providing better exception handling mechanisms that are less ugly. Dependency injection frameworks did a lot of that for us already, for a large class of applications -- and the code got a lot prettier, easier to write, and easier to read. AFAICS, the two biggest removable uglinesses of exceptions are repeated identical catch clauses and exception chaining.

The repeated catch clause problem is when you call a method that might throw exceptions A, B, C, and D, which do not have a common parent other than Exception, but you handle them all the same way. (Reflection is a major offender here.)

You'd like to fold the catch clauses together, because duplicated code is bad. Some people simply catch Exception, but this has a different meaning -- because RuntimeException extends Exception, you're also sweeping up unchecked exceptions accidentally. You can explicitly catch and rethrow RuntimeException before catching Exception -- but its easy to forget to do that.

Now, the wrap-and-rethrow technique is very effective -- it allows methods to throw exceptions that are at an abstraction level commensurate with what the method is supposed to do, not how it is implemented, and it allows you to reimplement without destabilizing method signatures. But it adds a lot of bulk to the code. Since this is such a common pattern, couldn't it be solved with some sort of declarative "rethrows" clause:

The rethrows clause is part of the implementation, not the signature, so maybe it goes somewhere else, but the idea is clear: if someone tries to throw an X out of this, wrap it with a Y and rethrow it.

An alternate approach to this would be possible with closures and reified generics; it would be possible to write a pseudo-control construct that said "execute this closure but if it throws X, wrap it with a Y and rethrow it." Unfortunately, with the current state of generics, we can't write such a generic method, we'd have to write a separate one for each exception type we want to wrap.

These approaches focus on the symptom -- because the arguments in group (2) are about symptoms. If we could alleviate the symptoms, people might grumble less.

The people in camp (3) are saying something slightly different. I don't really have an answer for them, because what they seem to be saying is that no matter what mechanism you give people for dealing with failure, they won't follow it. Checked exceptions were a reaction, in part, to the fact that it was too easy to ignore an error return code in C, so the language made it harder to ignore. This works on a lot of programmers who are slightly lazy but know that ignoring exceptions is unacceptable, but apparently is worse than nothing for some parts of the population. (We'd like to take away their coding rights, but we can't.)

Checked exceptions are a pain, and in some frameworks (like EJB before dependency injection), can be really painful. Once the ratio of "real code" to "error handling code" rises above some threshold, readability suffers greatly, and readability is a fundamental value in the Java language design. Even if the IDE generates the boilerplate for you, you still have to look at it, and there's a lot of noise.

On the other hand, my experiences using third party C++ libraries was even more painful than anything Java exceptions have ever subjected me to. Virtually no packages ever documented what might be thrown, so you end up playing "whack a mole" when exceptions did pop up -- and usually at your customers's site. If people are not forced to document what errors their code throws, they won't -- especially the people that the people in camp (3) are afraid of. As long as those folks are allowed to code, the value we get from checked exceptions forcing developers to document failure modes overwhelms the annoyances.

But, as I said above, I think many of the annoyances can be removed by adding a small number of exception streamlining constructs. This doesn't help Neal with simplifying closures, but it does help us get our job done with a little less pain.

Finally, a meta-note -- its really easy to misinterpret the volume of support for "removing checked exceptions" as any sort of gauge for community consensus. We're intimately familiar with the pain that checked exceptions cause; we're substantially less familiar with the pain that they free us from. (Obviously, neither approach is perfect, otherwise there'd be no debate.)

Monday, June 18, 2007

While reviewing my household budget recently, I realized that we had truly crossed into the information age -- we pay more for bits than we do for energy. (By bits, I mean both the infrastructure by which information is delivered to us in electronic form, and the content we purchase; by energy, I'm including only my home utility bills, not gasoline, but since I work at home, I'm guessing my gasoline consumption is lower than average.)

Sunday, June 17, 2007

I've been a Tivo addict since the first DirecTivo boxes came out. After getting a big screen TV, the standard definition picture looks pretty bad (especially as it seems that DirecTV compresses the hell out of their signals to make room for more pay-per-view channels.) So we wanted to upgrade to some sort of HD service, but of course Tivo is a must (no third-party DVRs -- no one who has had both a third-party DVR and Tivo has ever said anything good about the third-party DVRs.)

Option 1: DirecTV's HD Tivo. This was released a few years back, but is going to be incompatible with the HD locals that DTV is rolling out, which will be using a different encoding. (Some people have combined this solution with OTA HD, but I have no interest in playing games with antennas.) And DTV has yet to roll out HD locals in this area anyway, and there's little sign they're coming soon. So even if there was HD local channels here, there's no Tivo solution that can record them, only the DirecTV DVR.

Option 2: Digital cable + Series3 Tivo. This seems like the obvious choice, except for the high cost of the Tivo box (600+, plus the increased cost of the Tivo data service which I'd been insulated from since DTV customers were grandfathered in at the low rates). But...no TivoToGo or MRV on the Series3 yet, which means you can't transfer videos to the video iPod. This has to do with content restrictions surrounding their CableCard certification, but annoying it applies not only to protected HD but also to unprotected SD content. Ugh. (As to MRV, if you have two Series3 Tivos with CableCards, why is there a problem moving the content from one Tivo to another?)

Option 3: Comcast DVR with Tivo. Comcast did a deal with Tivo where you can get their Motorola DVR and upgrade to Tivo software as it is rolled out. But its going to be a long time before the rollout reaches here.

MythTV is not an option; you can't put a CableCard in a MythTV box.

So far, no hacks have appeared for the Series3 (other than those that involve reprogramming the PROM and resoldering it) that get around these restrictions.

We're going to bite the bullet and go with Option 2, and hope that eventually Tivo resolves its dispute with CableLabs and reinstates some form of TivoToGo and/or MRV.

Monday, June 4, 2007

I was in New York yesterday for my great-aunt's 90th birthday party. The party was over at six, and our flight wasn't until 11, but we figured that New York was a pretty good place to pass a few hours, so we weren't worried. But as the party was ending, it started to rain pretty hard, so we decided to just pack it in and head to the airport, even though JFK isn't the most fun place to kill a few hours.

Wandering around, I passed a half-asleep fellow camped out behind his laptop and thought "That looks an awful lot like Doug Lea". And it was -- he was on a six hour layover on the way home from Amsterdam (yuck). Usually the surprises you get at the airport are of the unpleasant variety, but not always.