Simon’s Blog

In software development, handling exceptions (”things that go wrong”) is a pain. It’s a (necessary) distraction from implementing the core functionality of a program. Not unsurprisingly then, every so often in the Java and/or C# development communities the question of how exceptions should be best handled comes up. Is it better to have “checked exceptions” or “unchecked exceptions”? It’s just happened again - you might want to read the comments if you’re not familiar with the arguments pro and con. Choosing checked or unchecked exceptions is a significant design decision in a programming language. However, both approaches can work quite well. Neither seem perfect to me (exceptions are always a pain), and there are advantages and disadvantages to both. To be honest, I find it hard to get excited about thinking which approach is “better”.

The only observation I would make about the “unchecked” side of the debate is that I’ve noticed that its proponents sometimes tend to be rather confident that they know what’s “best for everyone”, while actually have some rather surprising misunderstandings about programming.

Here’s a classic quote from Anders Hejlsberg, the designer of C#, from a few years ago that, I think, illustrates this rather nicely:

The trouble (with checked exceptions) begins when you start building big systems where you’re talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you have 80 exceptions in your throws clause. It just balloons out of control.

Now, let me be clear. I’m 100% sure that Anders knows many orders of magnitude more about language design than I do. And I’m 99.9% sure he knows similarly more than you do too! He is a super-talented guy. However, he’s just wrong here. The truth is that this almost never happens. Having 80 exceptions in a throws clause? Give me a break! And, when this kind of issue does arise, it’s more likely to be because of badly written code than anything else - and there’s not a lot you can do about that. In other words, this is in no way “typical” or “what happens” if a language has checked exceptions. There are no real issues of scalability with checked exceptions.

Now, if “scalability” was a central reason why Anders chose to make C# have only unchecked exceptions (and, by the way, it was), you might be within your rights to at least ask if it was the right decision. But I digress… The point is, if Anders doesn’t have a complete understanding of this issue, there really isn’t much hope for anyone else.

On balance, I guess my view on this debate is that checked exceptions are simply different to unchecked exceptions. Not particularly better or worse. Just different. You have to write your software in a different way, depending on whether you have checked or unchecked exceptions; indeed, this is the biggest diference between writing software in Java versus writing software in C#. But as I say, in the end, I find it hard to care about this…