Exception annotations, similar to nullable, and knowing exception details at compile time.

[lennoncork]

Have been thinking about the possibility of annotating Exception information in methods, similar to how nullable works. The goal would be to let the compiler determine (without knowing anything about how this could be achieved) what exceptions may be raised by a given method, and depending on how the method handles exceptions, the caller would be annotated with the same information. Maybe similar to #6079.

Given the following method

public void Method1(bool shouldThrow)
{
    if(shouldThrow)
    {
        throw new Exception("Method 1");
    }
}

A caller of Method1 would know that there is a possible exception thrown. If the exception were not handled in a way that the compiler understands, the annotation would propagate to the caller.

public void Method2()
{
     Method1(...);
}

Here Method2 is known to possibly throw an exception because of it's usage of Method1.

A try catch could be used to prevent the annotation from propagating.

public void Method3()
{
    try
    {
        Method1(...);
    }
    catch(Exception) { }
}

Here Method3 is known not to throw any exceptions.

Some additional annotation information could be achieved by attributes that developers can use to either suppress or override the compiler generated information.

// Option 1: An attribute on the class that overrides any compiler determined annotation. 
[doesnotthrow]
public void Method2
{
    bool shouldThrow = false;

   // Option 2: Signal to the compiler that the appropriate checks have been made and Method1 is known not to throw. 
   #doesnotthrow
   Method1(shouldThrow);
}

Here the updated Method2 would have the same annotations as Method3.

This example came up out of refactoring some older code to use nullable and discovering that some assumptions that were made in the past weren't obvious at the top or the caller tree. It would have been really nice to be able to track down the possible exception information with a system like above.

[lennoncork]

Looks like this maybe equivalent to the Java "throws" keyword, as discussed here. Agree it would be nice to see this functionality in C# with some of the automatic propagation suggested above.

[333fred]

Duplicate of #429, #4288, #2052, #2937, #947, and #3844. See also https://www.artima.com/articles/the-trouble-with-checked-exceptions, and interview with Anders on checked exceptions were not added to C# in 1.0.

[TahirAhmadov]

The question is, why? Take a web application, you handle most exceptions at the Handle method (or ProcessRequest(Async), whatever) and log the error. Same with desktop apps, whenever there is an exception, you catch it in some centralized manner, log the error and maybe show a message box.
In a specific context, say, trying to access the file system, you wrap the calls with try-catch for those exception types - because you actually need to handle them in a specific manner. Other than that, all the checked exceptions stuff is just clutter for no reason.

[DanFTRX]

The question is, why? Take a web application, you handle most exceptions at the Handle method (or ProcessRequest(Async), whatever) and log the error. Same with desktop apps, whenever there is an exception, you catch it in some centralized manner, log the error and maybe show a message box. In a specific context, say, trying to access the file system, you wrap the calls with try-catch for those exception types - because you actually need to handle them in a specific manner. Other than that, all the checked exceptions stuff is just clutter for no reason.

So while checked exceptions would generate clutter. Compiled annotations indicating which errors are thrown would not. Such a change would be purely informative with no changes required in code.

The value add is that exceptions would automatically be documented as part of compiled method metadata.

1. Information would be readily available to make determinations on whether or not a given function call needs a try-catch (I'm sure many first time C#ers are caught by surprise when they first get a DirectoryNotFoundException from File.Create)
2. Often libraries will have little/no/hard to find documentation, making finding truly exceptional exceptions a runtime surprise, as part of the method metadata it would be a matter of hovering the function in your editor to see a list of possible exceptions (assuming that's how the editor tooling chooses to utilize the metadata)

Now the negatives include:

1. Bloated binary size - mainly affects developers, end-user applications can mitigated by trimming the annotations during publish
2. Development time for this feature by the Roslyn/CSharp team
3. Development time to utilize the feature in a useful manner by tooling applications

The negatives may outweigh the positives depending on who you ask, but lets not pretend positives don't exist.

[CyrusNajmabadi]

It's unclear how this would work. Take, for example, any linq call. How does the system know that it will execute a delegate, and thus return any of the exceptions that delegate might throw (on top of any additional ones it might throw itself).

[DanFTRX]

It's unclear how this would work. Take, for example, any linq call. How does the system know that it will execute a delegate, and thus return any of the exceptions that delegate might throw (on top of any additional ones it might throw itself).

Oh there are plenty of complications that make actually implementing such a feature a herculean task if not impossible. Generics, delegates, dynamically loaded code. Plenty of places where I don't see how it could be done.
I was just commenting that the idea is not without merit from a purpose/useful perspective.

[jaredpar]

Take, for example, any linq call. How does the system know that it will execute a delegate, and thus return any of the exceptions that delegate might throw (on top of any additional ones it might throw itself).

This was a major issue when we implemented checked exceptions in Midori. Essentially how do you handle any overridable point (delegates, interfaces, virtual methods, etc ...) in this type of checking? It, combined with other effects like async, lead to combinatorial explosion of types:

void Action(); 
void ActionThrows() throws;
async Task AsyncAction();
async Task AsyncActionThrows() throws;

That is just for the simple throw / no throw casess. Midori heavily de-emphasized the idea of derived exception types. This problem is likely much worse in .NET where there is a much stronger emphasis on derived exception types.