Please add to C# language the "throws" keyword to mark methods, properties or constructors that may throw errors. Also, please add "try?", "try!" that will provide simple and fast way to handle errors.

[DeveloperLookBook]

This approach is used by Swift. And it's wonderful. I changed/adjusted/extended their syntax a little.

Method declaration might look like this:

 //This method can throw exception and is marked with appropriate keyword -> "throws"
public Type MethodsThatThrowsError(...) throws
{
     ///...    
}

Constructor declaration might look like this:

 //This constructor can throw exception and is marked with appropriate keyword -> "throws"
public ConstructorName(...) throws  
{
}

Property declaration might look like this:

 //This properties can throw exception and are marked with appropriate keyword -> "throws"
public Type PropName { get throws; set throws; }
public Type PropName { get throws; }
public Type PropName throws => // expression;
public Type PropName 
{ 
    get throws 
    {
    } 
    set throws
    {
    }
}

Main way to handle exception in method/property/constructor marked with “throws” keyword:

Type SomeMethod() 
{
    try 
    {
        // "Try...Catch" construction is required  for the methods/properties/constructors that were marked with "throws" keyword
        MethodsThatThrowsError(...) 
    } 
    catch 
    {
    }
}

Type SomeMethod() throws
{
     //Try...Catch"/"try?"/"try!" construction can be omitted if methods/properties/constructors are invoked within the  body of the methods/properties/constructors that are marked with "throws" key word
      MethodsThatThrowsError(...)  
}


Type SomeMethod?()  // method/property/constructor returns value or Null if it throws an error and its name contains "?".
{
     //Try...Catch"/"try?"/"try!" construction can be omitted if methods/properties/constructors are invoked within the  body of the methods/properties/constructors that are marked with "?" operator
      MethodsThatThrowsError(...)  
}

Type SomeMethod!() // method/property/constructor returns value or Null if it throws an error and its name contains "!".
{
     //Try...Catch"/"try?"/"try!" construction can be omitted  if methods/properties/constructors are invoked within the  body of the methods/properties/constructors that are marked with "!" operator
      MethodsThatThrowsError(...)  
}

Alternatively to the “try… catch” blocks full declaration we can use it’s shortcut:

Type SomeMethod() 
{
    try? MethodsThatThrowsError(...); // method/property/constructor returns value or Null if method throws error. Full "Try...Catch" construction  is not required for the methods  marked with "throws"   keyword if they were invoked with "try?" 
}

try! MethodsThatThrowsError(...); // method/property/constructor returns value or Throws RunTime exception if method throws error. Should be used if developer is sure that method that was marked with "throws" keyword will never throw any errors. "Try...Catch" construction is not required for the methods marked with "throws" key word if they were invoked with "try!"

Concepts:

• All methods/properties/constructors marked with “throws” must be handled by the developer with “try … catch”/“try?”/“try!”.
• IDE should notify developer if such methods/properties/constructors were not handled by throwing compile time error.
• IDE should highlight such method/property/constructor invocations if they were done without try {} catch() {} blocks.
• Add a possibility to use “try?” and “try!” operators with methods/properties/constructors that are marked with “throws” key word to suppress error propagation and to handle it.
• Add a possibility to declare method/property/constructor names with “?” and “!” operators to suppress error propagation and to handle it.
• Such concept is very handy and makes error handling more obvious/declarative.

[HaloFour]

See: #429

[DeveloperLookBook]

@DeveloperLookBook

SomeClass instance = try? MethodThatThrowsSomeException(); // Returns null if method throws exception

This would be a terrible pattern to encourage by enshrining it with special syntax. Silently swallowing an exception is rarely the right thing to do.

Okay. Looks like I am wrong and this is a bad idea.

[CyrusNajmabadi]

i agree with @HaloFour here. That looks like an antipattern. Exceptions should bubble up to the point that can effectively handle them with some reasonable strategy (crash process, retry, log, telemetry, recycle, etc.). Generally speaking, silent swallowing is almost never ok, and def not something we woudl want to make easy.

[RikkiGibson]

Swift has avoided "coloring" their functions, at least in some places, via use of rethrows. For example the standard map function signature is:

func map<T>(_ transform: (Self.Element) throws -> T) rethrows -> [T]

This signature expresses that the function can only throw if one of its inputs can throw. So if you pass in a lambda which could throw an error then you will have to handle the error outside the call (i.e. call inside a do-try block, try? or try!). If your lambda can't throw an error then you won't need to handle the error outside the call.

I don't know where the limitations might be as far as: if you have sufficiently complex scenario X, there's some cliff where you now need to declare throwing and non-throwing versions of something. It would be interesting to find out.

All that said, it's very difficult to imagine introducing a checked exceptions system in C#. I think it would end up being a bolted-on mode enabled by settings/directives like nullable reference types, and, well... that feature was a huge amount of work to design, implement, and for people to adopt. Checked exceptions just aren't at that level of need. Perhaps community members who find that interesting could consider designing some scheme of attributes and analyzers to do something like it.

This would be a terrible pattern to encourage by enshrining it with special syntax. Silently swallowing an exception is rarely the right thing to do.

I personally don't think that try? is terrible. It may not be the right thing for C#, but I don't think that Swift necessarily made a mistake by including it in their error handling design. I do think that some expression form of try-catch-finally could be a good thing for C#, which would also make it easier for people to "throw away" exceptions in the middle of expressions, however folks may feel about that.

[HaloFour]

@RikkiGibson

Swift has avoided "coloring" their functions, at least in some places

That's an interesting feature and it probably helps in some cases, but I don't think it avoids the color function issue as much as it blurs the lines in a handful of those select cases. I can't imagine that works with any kind of deferred evaluation, like LINQ or Java streams (where checked exceptions are extremely annoying). Either way, collapse the wave function and you still end up with a function of a particular color and that impacts where and how you can call that function.

I personally don't think that try? is terrible. It may not be the right thing for C#, but I don't think that Swift necessarily made a mistake by including it in their error handling design.

Maybe. Different languages and frameworks have different philosophies when it comes to errors. I can't speak to the specifics with Swift, but if it's a lot less expensive to throw you might be much more likely to encounter methods that are expected to throw for minor reasons and less reason to provide non-throwing versions, e.g. the Try* pattern. If exceptions are less exceptional then it's less concerning to throw them away (pun intended).

I do think that some expression form of try-catch-finally could be a good thing for C#, which would also make it easier for people to "throw away" exceptions in the middle of expressions, however folks may feel about that.

I would also like an expression version of try, but I'd prefer it to be more like switch expressions. I think it would fit well given exception handling has always been kind of like type patterns. Although I kind of think it's unfortunate that in F# you're forced to match expressions and exceptions separately using match...with and try...with respectively.

[RikkiGibson]

I can't imagine that works with any kind of deferred evaluation

It doesn't look like it does: https://developer.apple.com/documentation/swift/lazysequence/map(_:)-5eh3s

[AartBluestoke]

catch ( Exception ex) { // specifically Exception, which is what this would have to be implemented as
// do anything that doesn't throw
}
is also specifically an anti pattern; you are only supposed to catch exceptions you can deal with - almost no catch handler knows how to handle StackOverflow, OutofMemory, ThreadAbort, ExecutionEngineException, Access Violation, and various others ...

Any given catch should only specifically handle those things it can guarantee it can return a safe state from - eg: reading from a database you can handle catch sql, network, and serialization errors safely, as that code generally knows what to do if it can't get the thing it asked for.

[chylex]

Exceptions are extremely frustrating to deal with, and not having a way to enforce a try/catch around a method is even more so.

It's far from the first time I'm frustrated, but right now I'm writing a UI in Avalonia, where letting exceptions bubble up through command bindings means the exception just disappears. No logs or error message dialog is terrible for users, so I have to put a try/catch everywhere around sensitive methods. But even if I know which methods are sensitive, C# gives me no tool to enforce that those exceptions are handled.

[chylex]

The exception has the details as to what happened, where and why.

An exception absolutely does not have the necessary information for displaying something reasonable to the user. Exceptions and exception messages are a mess.

An exception like System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found) is barely enough information. Maybe it's enough if the URL was user input, but otherwise you have no idea what the URL was, or what was the purpose of the request. If this appeared randomly because of a periodic software update check in the background, that bubbled up into the generic exception handler, showing just the raw exception message would be completely useless to the user who has no idea what just happened.

Forgetting to catch OperationCanceledException or TaskCanceledException is quite easy, even though every single method that takes a CancellationToken can throw it, and you want to handle it so it doesn't get pointlessly printed out to the log, sent to Sentry, or shown in an error dialog, every time a user clicks a Cancel button.

These are good candidates for exceptions that happen all the time, are of particular interest for programmers to catch and handle, but the language has no way of enforcing that even if the programmer wanted it.

Java's checked exceptions have demonstrated exactly why a model like this doesn't work, tons of noise for very little actual gain.

I've been writing both C# and Java for over 12 years and I feel the exact opposite. I used to dislike Java's checked exceptions, but over the years I found them more and more convenient.

If I'm designing an API that I know can experience a few particular types of errors, and I don't have the comforts and syntax sugar of Rust's Result type, then I will create new checked exception types to make sure they get caught by anyone who forgets to check the documentation. If I need to handle a new type of error, I can add it to the list, and the compiler will warn me about all the places that need to handle it. It's certainly flawed, but it's a model that certainly has valid uses and works.

[HaloFour]

I don't see convenience in forcing the immediate caller to have to deal with an exception when the vast, vast majority of the time there is nothing they can do about it aside bubbling it up to a higher context. And if you're implementing a contract that doesn't throw you have no good choices, you end up having to squash the exception or wrap it in an unchecked exception, which defeats the entire purpose. This is especially problematic with functional interfaces and hybrid functional libraries like Java Streams or Reactor. I think it's pretty telling that almost all of the other JVM languages ignore checked exceptions outright, and a lot of exceptions in frameworks are simply unchecked.

I think the team has been pretty clear that they're not interested in Java-style checked exceptions. If someone can demonstrate another model which eliminates the many downsides of checked exceptions then maybe there could be a conversation about it.

[chylex]

I don't see convenience in forcing the immediate caller to have to deal with an exception when the vast, vast majority of the time there is nothing they can do about it aside bubbling it up to a higher context.

That's just not the case in the codebase I work in.

And if you're implementing a contract that doesn't throw you have no good choices, you end up having to squash the exception or wrap it in an unchecked exception, which defeats the entire purpose.

At these points, the exceptions get wrapped in a Result<T, E> type that is generic over the exception type (or a variation that is generic over multiple exception types). Then there is an unwrap method that is declared as throws E. You can carry this Result through streams or other non-throwing boundaries, and when you unwrap it, the compiler forces you to catch whatever E is, if E is a checked exception type.

The Result type in that particular codebase was designed before Java had switch expressions, maybe it would be designed differently nowadays, but it's worked well. Constructing the Result from a throwing method is a little annoying, but if you need to handle exceptions inside stream operations for example, it will get ugly either way.

I think the team has been pretty clear that they're not interested in Java-style checked exceptions. If someone can demonstrate another model which eliminates the many downsides of checked exceptions then maybe there could be a conversation about it.

I didn't necessarily ask for checked exceptions in C#, I asked for better tooling that solves the problem checked exceptions solve. Maybe an attribute that declares an exception type, and a compiler warning if you ignore it. Maybe better ways to deal with async in event handlers. Maybe better support for discriminated unions, with built-in Result-style types and .NET APIs that return those, instead of throwing.

I strongly dislike exceptions in general, but removing exceptions from .NET seems unrealistic, so all I can hope for it better tooling around them.

[HaloFour]

Maybe an attribute that declares an exception type, and a compiler warning if you ignore it.

You can accomplish this with analyzers: https://github.com/tetractic/ExceptionAnalyzers

[chylex]

You can accomplish this with analyzers: https://github.com/tetractic/ExceptionAnalyzers

I will look at it in more detail later, but it looks like this will solve a lot of the problems I have with .NET exceptions, thanks!