C# Checked exceptions

One feature I really l开发者_JAVA百科iked in Java that isn't in C# is checked exceptions. Is there any way to simulate (maybe via stylecop?) or turn on checked exceptions in Visual Studio?

Yes I know a lot of people dislike them, but I find they can be helpful.

---

Far as I know, there's no way to do checked exceptions in C#. That feature (or a bug, depending on how you look at it :)) is not supported by the language.

Your best bet would be to add XML comments to your method, include the exceptions thrown by it and hope whoever calls your code reads the documentation.

Something like this:

/// <summary>
/// This is my method that does stuff.
/// </summary>
/// <exception cref="InvalidOperationException">This stuff can't be done!</exception>
public void DoStuff() 
{
    // do stuff
}

---

I bet you could use a tool like PostSharp to implement checked exceptions. Something like:

[Throws(typeof(MyExpection))]
public void Method()
{
   throw new MyException();
}

Not sure if something like this already exists in PostSharp or some other AOP framework (and the reasons why the designers of .NET don't like checked exceptions still hold true) but I bet it would be possible to do.

---

To the question: "Is there any way to simulate (maybe via stylecop?) or turn on checked exceptions in Visual Studio?" - Yes: try this Visual Studio extension: https://marketplace.visualstudio.com/items?itemName=YoavFrandzel.CheckedExceptions

---

Checked exceptions were included in Java because of the fallacious idea that caller of a method must understand all the ways the called method can possibly fail. This idea is now known to be wrong. As such, checked exceptions are a harmful legacy concept, and should be avoided.

The original Java rationale for checked exceptions was to fix the fragile C-style way of dealing with errors. C indicated an error by returning a special value, such as -1, NULL or NaN. This return value had to be be manually checked, otherwise the error would get ignored. Because the checking was tedious and verbose, it was frequently omitted by C programmers, leading to failures.

Checked exceptions were a misguided way to force the programmer to "check the return value". What Java designers did not fully understand at the time, is that with exceptions there is no need to "check the return value". An exception in absence of a handler does not get ignored. C return value does.

Moreover, exceptions are not part of the public interface of a method. They are an implementation detail, subject to change. For example, a method:

BigInteger fibonacci(BigInteger n)

might return a large Fibonacci number by calculating it. At some point, the implementation of the method might be optimized to read large numbers from a cache file instead. Suddenly, a plethora of new I/O exceptions can be thrown by the method, that were not present before!

The calling code can not, and should not know what exceptions might possibly be thrown by a method. The calling code should assume a method can throw any exception whatsoever.

Fortunately, such assumption does not mean the code of the calling method must be complicated. In an overwhelming majority of cases, the correct way to deal with an exception is to let it propagate up the stack. Not incidentally, this is the default behavior when programmer does nothing, and this is what makes exceptions such an elegant and terse way to manage errors.