Add Checked Exception feature to C#

[a14907]

There is no way to know what Exception the method will throw, we can only beg the mercy from the author to write the comment in their code! It is Weird!
Add Checked Exception feature to C#! It is too free to get a unexpected exceptions now!

[theunrepentantgeek]

The Trouble with Checked Exceptions - a conversation with Anders Hejlsberg.

So, if you want checked exceptions in C#, what's your design proposal? How do you avoid the versioning and scaling issues articulated by Anders in the above interview?

[HaloFour]

And that was written long before Java attempted to go functional. Checked exceptions work exceptionally poorly (har har) in a functional world since they cannot be composed. You end up having to write try/catch statements in what would otherwise be single expression lambdas because that expression might throw, and there's nothing you can do with that caught exception except for throw as an unchecked exception. It's no wonder so many of the other JVM languages, like Clojure, Kotlin and Scala, just ignore checked exceptions.

[a14907]

The Trouble with Checked Exceptions - a conversation with Anders Hejlsberg.
So, if you want checked exceptions in C#, what's your design proposal? How do you avoid the versioning and scaling issues articulated by Anders in the above interview?

Maybe we need union type to do some help!

[ronnygunawan]

IMO, checked exception should be implemented like NRT static analysis rather than using throws keyword. We can annotate runtime methods (requires method call attributes), classes, and events with attributes like [DoesNotRecoverFromException] to raise warnings whenever a "top level" public API, lifecycle method, or event handler which gets called from the annotated runtime methods throws an uncaught exception.

This warnings then prompt us to catch all the uncaught exception, or suppress the warnings, or optionally crash the app programmatically.

How do you avoid the versioning and scaling issues articulated by Anders in the above interview?

On versioning: This approach infers the list of thrown exception instead of requiring us to explicitly annotate methods with throws, I think this is easily versionable.

On scaling: Since we only care about uncaught exception thrown by "top level" methods, compiler can first build a graph of calls originating from these methods, then the compiler build graph of throws only for codes reached by the graph of calls. Both graphs can be rebuilt incrementally.

// Page_Load gets called by the runtime.
public async void Page_Load()
{
    // warning: OperationCanceledException is uncaught.
    //          Catch all exceptions to avoid crash.
    this.Title = await GetTitleAsync(CancellationToken.None);
}

// GetTitleAsync doesn't get called directly by runtime. It doesn't raise the warning.
public async Task<string> GetTitleAsync(CancellationToken cancellationToken)
{
    ...
}

Or we can annotate our own code with the attribute:

[DoesNotRecoverFromException]
public void Foo()
{
    // warning: IOException is uncaught
    //          Catch all exceptions to avoid crash.
    throw new IOException();
}

[Nevynette]

I'm curious.

Have Microsoft (or anyone else) tried this kind of static analysis to try find uncaught exceptions in non trivial applications?

Without annotations and tooling, my gut feeling is telling me that the nitpicking and false positives would ruin the experience and might be more of a hindrance than help.

[huoyaoyuan]

Have Microsoft (or anyone else) tried this kind of static analysis to try find uncaught exceptions in non trivial applications?

They don't catch exceptions that not recoverable at the medium level. The specified failure of a type of task will have a general base type, and highlighted in the documentation.

[orthoxerox]

Checked exceptions as implemented in Java won't work very well.

1. Derived classes may throw more derived exceptions, but you can't express this in your code. Even if you tell the authors of interfaces and base classes to annotate their code with exceptions (and maybe even generic exceptions!), you still have 20 years of existing code that won't work with that.
2. Higher-order functions are even worse. You can't say "my method throws FooException and also whatever exceptions this delegate parameter might throw other than BarException, because I catch and handle it".

On the other hand, I have to admit that when Java checked exceptions do work, they are a pleasure to work with. If Microsoft ever decides to write a language for the next few decades, it should definitely let you express failed states explicitly and with sufficient granularity.

[HaloFour]

I'd be happy to see good DU support that would enable Try<T> or Either<L, R> monads to stand in as checked exceptions, possibly with additional language support. Whatever it is it should work well with composing functional and fluent APIs.

I noticed that OP didn't explicitly mention Java's checked exceptions, although they seem to be the prototypical implementation that people refer to. I'd be game to explore what checked exceptions might look like if implemented with functional programming in mind. I'd be happy to hear how other languages may have implemented them differently that void the pitfalls of the Java implementation. But unless we can come up with something that "moves the art forward", it's better to not try to add it to the language.

[redradist]

Here is more detail proposal #2052 and it fits with what I wanted myself to propose =)