Handcuffs

It's been almost a year now since I've been writing Java codes since I was deployed to my current project. I used to write .NET C# codes for almost 4 years back in the academic world. Just yesterday, I was given a change to apply my .NET skills again to solve a real-world problem and fix a bug in a special browser application. In my experience in Java, I have been using "throws" keyword when writing a library to require the caller to catch exceptions that could possibly occur in the library. This feature is called "Checked Exceptions". But, I was surprised to find out that C# does not support this feature. So, i did a few searches on why did'nt Anders Hejlsberg, the lead designer of C# Language, didn't include this when in fact I find it useful when I was writing in Java. Then I found this interesting link which describes the reason behind this.

The converstation in the article state clearly that the designer decided not to include checked exceptions in C#. I like the lines Anders said when he was asked if there was disagreement in the C# design team about checked exceptions.

Anders Hejlsberg: No, I think there was fairly broad agreement in our design group.

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.

If you ask beginning programmers to write a calendar control, they often think to themselves, "Oh, I'm going to write the world's best calendar control! It's going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."

Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like.

Bruce Eckel: The Extreme Programmers say, "Do the simplest thing that could possibly work."

Anders Hejlsberg: Yeah, well, Einstein said that, "Do the simplest thing possible, but no simpler." The concern I have about checked exceptions is the handcuffs they put on programmers. 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.

I have a total agreement on the handcuffs thing. I didn't realize that until I read this. I used to think that checked exception is very useful, well.. maybe it is in some ways like reminding the programmer to always catch such exceptions.. like what i did in my previous Java codes. But I also had these feeling of having no choice when the compiler tells you what to do specially when you call a method in a compiled library that throws more than 5 exceptions. What if you call 50 methods in this library and each throws 3 different kinds of exceptions? Hmm... all I can say is that I felt the handcuffs Anders was referring too. You don't want to put handcuffs to other programmer/users of your library, don't you?

Check this interesting argument: http://bytes.com/forum/thread259125.html