Bill Venners and Bruce Eckel interviewed Anders Hjelsberg on the topic of checked exceptions. My contention has long been that checked exceptions are a good thing, but that the way that they've been used in the Java API's is a disaster. These two quotes support that idea.

Frankly, they look really great up front, and there's nothing wrong with the idea. I completely agree that checked exceptions are a wonderful feature. It's just that particular implementations can be problematic. By implementing checked exceptions the way it's done in Java, for example, I think you just take one set of problems and trade them for another set of problems. In the end it's not clear to me that you actually make life any easier.

Checked exceptions are good.

You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.

API designers are using them wrongly.

So far, no disagreement.

The Hjelsberg brings up two areas that I haven't seen discussed before (or at least not from this point of view): the impact of checked exceptions on versioning of classes/interfaces, and the issue of scalablity. The scalability one is particularly convincing for me.

The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble 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've got 80 exceptions in your throws clause. It just balloons out of control.

Even if API designers use checked exceptions correctly, the blow up certainly causes problems. But what's the solution here? I like the idea of checked exceptions, but this inability to scale is evident in large Java programs.

C# is basically silent on the checked exceptions issue. Once a better solution is known-and trust me we continue to think about it-we can go back and actually put something in place. I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework.

This seems like wisdom to me. Study the problem some more, get some more practical experience and then add a truly useful feature. I can respect that.

And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks. I don't think we can construct hard and fast rules down to, it is either a compiler error or not. But I think we can certainly do a lot with analysis tools that detect suspicious code, including uncaught exceptions, and points out those potential holes to you.

This is a variant of what I've been saying regarding the static vs dynamic typing issue. Maybe it really does make sense to keep some features like static types and checked exceptions out of the language, and provide better analysis tools that can be run over the code. If these tools became part of the programming environment, then their warnings would be indistinguishable from compiler errors or warnings.