Wednesday, October 15, 2008

[.NET] Why are Exceptions not Checked in C#?

Going from Java to C#, I've been stunned by the absence of  the "throws" clause in the declaration of a method, in which you want to throw a particular exception.
Actually it hasn't caused me so much pain, but the knowledge at compile time of the possibility that an exception could be thrown sounded very useful to me.
Asking to the StackOverflow community, I found out Java is one of the few programming languages where exceptions are "caught" at compile time.
The philosophy behind C# is that what is useful about exceptions is not handling them, but mostly cleaning resources, implementing the IDisposable pattern (The trouble with Checked expcetions).
If you know that a particular method can throw an exception, you also know what it does and how to handle it, otherwise you will handle a generic exception, without need to specify it at compile time; moreover handling exceptions is something that comes near the caller of a method reather than the method itself, so there is no need to specify a chain of "throws" declarations, and that is so useful in versioning, because adding a new exception (or removing an old one) doesn't require a refactoring of your lib.
It is worth noting that C# supports the <exception> tag in the documentation section, with which the compiler informs you that an exception (whose type is anyway checked for existence) can be thrown, without any further constraints.
If you have other issues or different opinions I'd like to hear them.

Good butchering!

3 comments:

alexbl said...

My experience with checked-exceptions in Java is that they actually lead to worse exception handling then to better. More often then not when implementing an interface that doesn't throw, you're forced to internally deal with exceptions, and the fastest way to internally deal with exceptions when developing is to ignore them. So you get a lot of code like:

try {
doSomethingThatThrows();
catch (Exception e) {
// XXX handle me later...
}

And then, minutes/hours/days/months later when doSomethingThatThrows() actually throws, it becomes significantly harder for you as a developer to diagnose the problem.

Casper Bang said...

I agree, checked exceptions are one of those things that sounds nice but causes all sorts of problems and gets in the way.

Thankfully, most newer frameworks in Java use no, or very few, checked exceptions.

Anonymous said...

Yes. Most newer Java APIs do not include checked exceptions because really checked exceptions belong at the domain level.