Why are Exceptions not Checked in .NET?

Question

I know Googling I can find an appropriate answer, but I prefer listening to your personal (and maybe technical) opinions.
What is the main reason of the difference between Java and C# in throwing exceptions?
In Java the signature of a method that throws an exception has to use the "throws" keyword, while in C# you don't know in compilation time if an exception could be thrown.

Answer 1

The basic design philosophy of C# is that actually catching exceptions is rarely useful, whereas cleaning up resources in exceptional situations is quite important. I think it's fair to say that using (the IDisposable pattern) is their answer to checked exceptions. See [1] for more.

1. http://www.artima.com/intv/handcuffs.html

Answer 2

Because the response to checked exceptions is almost always:

try {
  // exception throwing code
} catch(Exception e) {
   // either
   log.error("Error fooing bar",e);
   // OR
   throw new RuntimeException(e);
}

If you actually know that there is something you can do if a particular exception is thrown, then you can catch it and then handle it, but otherwise it's just incantations to appease the compiler.

Answer 3

I went from Java to C# because of a job change. At first, I was a little concerned about the difference, but in practice, it hasn't made a difference.

Maybe, it's because I come from C++, which has the exception declaration, but it's not commonly used. I write every single line of code as if it could throw -- always use using around Disposable and think about cleanup I should do in finally.

In retrospect the propagation of the throws declaration in Java didn't really get me anything.

I would like a way to say that a function definitely never throws -- I think that would be more useful.

Answer 4

Additionally to the responses that were written already, not having checked exceptions helps you in many situations a lot. Checked exceptions make generics harder to implement and if you have read the closure proposals you will notice that every single closure proposal has to work around checked exceptions in a rather ugly way.

Answer 5

By the time .NET was designed, Java had checked exceptions for quite some time and this feature was viewed by Java developers at best as controversial. Thus .NET designers chose not to include it in C# language.

Answer 6

Interestingly, the guys at Microsoft Research have added checked exceptions to Spec#, their superset of C#.

Answer 7

I sometimes miss checked exceptions in C#/.NET.

I suppose besides Java no other notable platform has them. Maybe the .NET guys just went with the flow...

Answer 8

In the article The Trouble with Checked Exceptions and in Anders Hejlsberg's (designer of the C# language) own voice, there are three main reasons for C# not supporting checked exceptions as they are found and verified in Java:

• Neutral on Checked Exceptions

  “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.”

• Versioning with Checked Exceptions

  “Adding a new exception to a throws clause in a new version breaks client code. It's like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, …”

  “It is funny how people think that the important thing about exceptions is handling them. That is not the important thing about exceptions. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. Or in C#, using statements, which are like try finally.”

• Scalability of Checked Exceptions

  “In the small, checked exceptions are very enticing…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.… It just balloons out of control.”

In his article, “Why doesn't C# have exception specifications?”, Anson Horton (Visual C# Program Manager) also lists the following reasons (see the article for details on each point):

• Versioning
• Productivity and code quality
• Impracticality of having class author differentiate between checked and unchecked exceptions
• Difficulty of determining the correct exceptions for interfaces.

It is interesting to note that C# does, nonetheless, support documentation of exceptions thrown by a given method via the <exception> tag and the compiler even takes the trouble to verify that the referenced exception type does indeed exist. There is, however, no check made at the call sites or usage of the method.

You may also want to look into the Exception Hunter, which is a commerical tool by Red Gate Software, that uses static analysis to determine and report exceptions thrown by a method and which may potentially go uncaught:

Exception Hunter is a new analysis tool that finds and reports the set of possible exceptions your functions might throw – before you even ship. With it, you can locate unhandled exceptions easily and quickly, down to the line of code that is throwing the exceptions. Once you have the results, you can decide which exceptions need to be handled (with some exception handling code) before you release your application into the wild.

Finally, Bruce Eckel, author of Thinking in Java, has an article called, “Does Java need Checked Exceptions?”, that may be worth reading up as well because the question of why checked exceptions are not there in C# usually takes root in comparisons to Java.

Answer 9

Fundamentally, whether an exception should be handled or not is a property of the caller, rather than of the function.

For example, in some programs there is no value in handling an IOException (consider ad hoc command-line utilities to perform data crunching; they're never going to be used by a "user", they're specialist tools used by specialist people). In some programs, there is value in handling an IOException at a point "near" to the call (perhaps if you get a FNFE for your config file you'll drop back to some defaults, or look in another location, or something of that nature). In other programs, you want it to bubble up a long way before it's handled (for example you might want it to abort until it reaches the UI, at which point it should alert the user that something has gone wrong.

Each of these cases is dependent on the _application, and not the library. And yet, with checked exceptions, it is the library that makes the decision. The Java IO library makes the decision that it will use checked exceptions (which strongly encourage handling that's local to the call) when in some programs a better strategy may be non-local handling, or no handling at all.

This shows the real flaw with checked exceptions in practice, and it's far more fundamental than the superficial (although also important) flaw that too many people will write stupid exception handlers just to make the compiler shut up. The problem I describe is an issue even when experienced, conscientious developers are writing the program.

Answer 10

Anders himself answers that question in this episode of the Software engineering radio podcast