Bill Venners has a couple of interviews with both James Gosling and Anders Hejlsberg that cover the issue of exception handling. The curious thing about exception handling is that nobody can come to agreement as to what’s best. That’s probably because nobody has a good grasp of how best to handle it.
However, lets get to the main point of this article, that is both Gosling and Hejlsberg are both wrong. That is the inventor of Java and the inventor of C# have both a crummy understanding of the matter.
First here’s what Gosling says when pressed on the matter:
Bill Venners: Have you seen the throw clause scalability problem in your visits out in the industry?
James Gosling: I’ve never seen issues where people have a gazillion items in their throws clause. Three, four, or five, maybexe2x80x94and even those numbers are rather large. Almost always it’s zero or one.
I’m simply stunned, forms of static checking like checked exceptions tend to have problems scaling. To say that he hasn’t seen it is more like trying to wish the problem away by refusing to see it.
Now here’s what Hejlsberg has to say:
The throws clause, at least the way it’s implemented in Java, doesn’t necessarily force you to handle the exceptions, but if you don’t handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause.
Hejlsberg may have spoken incorrectly here, that’s because you can declare a throws clause using an unchecked exception and the client isn’t forced to handle it. The utility of this technique is that its easy for a programmer or even a program (i.e. Eclipse) to discover what kind of exceptions a method may throw. This highlights the inadequacy of the C# language itself, in its desire to maintain compatibility with VB.NET, the designers removed this feature from the language, essentially depriving the masses of a way to handle exceptions at a local level.
Both seem to be holding to the party line, ignoring the true arguments, the fact is plain and simple, both languages do not adequately address the problem. That’s because it’s outside the realm of Object Oriented Programming where both Java and C# derive their underpinnings.
In fact, if you want to gain Nirvana on this you’ll have to climb the Aspect Oriented Programming mountain and seek the guru. That guru is Ron Bodkin and he’s got a very interesting set of presentations on how to apply AOP. The path to true wisdom is outside the confines of ordinary thinking. Fortunately, Hejlsberg at least admits ignorance on the matter:
Once a better solution is knownxe2x80x94and trust me we continue to think about itxe2x80x94we 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.