[Proposal]: Try Expressions

[ahives]

Summary

Currently, if we want to handle multiple exception types in C# we must do the following:

try
{
	...
}
catch (SomeException e)
{
	...
}
catch (SomeOtherException e)
{
	...
}
catch (Exception e)
{
	...
}

The compiler will check for the target exception in the order in which the exception handlers were declared (i.e., SomeException, SomeOtherException, ..., etc.). However, there is one caveat, that is, if you declare a handler that matches on System.Exception then it acts to shortcircuit subsequent handlers. This is exceptable since the compiler will error on this because System.Exception essentially hides all other handlers from executing since they derive from System.Exception. This works but it suffers from a couple problems:

• It is verbose in that one has to constantly write catch (...) { ... } syntax for each handler
• It looks similar to old style switch syntax

Motivation

C# 8 introduced switch expressions which presented a natural evolution of the switch syntax away from the decades old if-else style that its the try-catch pattern to something more expressive that is step with other modern languages. In C# 7 pattern matching was introduced for switch statements to allow for matching on object types. The language is already going in the direction of enabling pattern matching in branch logic. Try expressions are the next logical step toward enabling application developers to create expressive patterns to handle exceptions.

Proposal

The purpose of this proposal is to introduce functionality in the C# programming language that would make handling exceptions:

• More expressive error handling to enable programs to be written with pattern matching
• Less verbose to reduce the need to write catch(...) { ... } logic for each exception handler
• Easier to grok by programmers coming from other languages for which they are already familiar with such syntax (see Elixir)

For the reasons I propose the following syntax I am calling try expressions:

try
{
	...
}
catch
{
	SomeException e => ...,
	SomeOtherException e => ...,
	_ => ...
}

This proposed language feature is similar to the switch expression syntax. A few things to notice:

• There is no need to explicitly state that you are handling a System.Exception. Instead, you could simply use an underscore, _, catch all expression to represent the catch all case.
• If you wanted to pattern match conditionally you could use the when keyword like so,

try
{
	...
}
catch
{
	ExceptionType [e] when (expression) => ...,
	_ => ...
}

A working example looks something like this ,

try
{
	...
}
catch
{
	SomeException e when e.Message.Contains("xyz") => ...,
	SomeException e when e.Message.Contains("abc") => ...,
	_ => ...
}

The thinking here is that the handler could be a simple expression that could return a value or void. For more complex tasks there could be a code block such that you do something like this,

try
{
    // do something interesting here
}
catch
{
    SomeException e => /* do something simple here */,
    SomeOtherException e => { /* do something a bit more complex here */ },
    _ => ...
}

In the case that it is an expression that returns a value you should be able to use it like this,

Result result =
    try
    {
        return new Result(...);
    }
    catch
    {
        SomeException e => return new Result(...),
        SomeOtherException e => {
            ...
            return new Result(...);
        },
        _ => ...
    }

In the functional programming the idea is to reduce the application from blowing up by all means possible. So, in some instances you don't want exceptions to bubble up the call chain. Instead, you want to return a monad that has error information so that the caller can deal with it more appropriately. This sort of pattern can already be done like so,

public Result DoSomething()
{
    try
    {
		...
        return new Result();
    }
    catch (SomeException e)
    {
		...
        return new FaultedResult();
    }
    catch (SomeOtherException e)
    {
		...
        return new FaultedResult();
    }
    catch (Exception e)
    {
		...
        return new FaultedResult();
    }
}

Notice a couple of things:

1. The syntax is pretty verbose
2. The code cannot be used with the expression body syntax

Let's reimagine the above code with what is being proposed using expression body syntax,

public Result DoSomething() =>
    try
    {
		...
        return new Result();
    }
    catch
    {
    	SomeException e => new FaultedResult(),
    	SomeOtherException e => {
			...
        	return new FaultedResult();
        },
        _ => new FaultedResult()
    }

There is precedence for this expressive pattern both in C# and other languages like Elixir. For reference I provided a link to Elixir docs here to show how it is being used in other languages.

Drawbacks

I don't see any drawbacks since current applications will continue to work as they currently do upon upgrading to a version with try expressions released to the runtime. Also, this pattern is inline with work done in previous versions of the runtime including switch expressions, pattern matching, and expression body syntax.

Alternatives

As noted previously there are current ways to express error handling both conditionally and otherwise. However, it would be a bit strange to implement expression syntax in branch logic for switch statements and not do so for try-catch statements.

[TahirAhmadov]

The question here is, what happens in that "switch case" where you have ...? Is it an expression? If so, what happens to its value?

[ahives]

Hi Tanhir,

Good question. My thinking on that is that it could be a simple expression that would for returned values and for more complex tasks performed there would be a code block such that you do something like this,

try
{
    // do something interesting here
}
catch
{
    SomeException e => /* do something simple here */,
    SomeOtherException e => { /* do something a bit more complex here */ },
    _ => ...
}

In the case that it is an expression that returns a value you should be able to use it like this,

Result result =
    try
    {
        return new Result(...);
    }
    catch
    {
        SomeException e => return new Result(...),
        SomeOtherException e => { return new Result(...); },
        _ => ...
    }

Why would we ever want to return a value? Well, in the functional programming world of things the idea is to reduce the application from blowing up by all means possible. So, in some instances you don't want exceptions to bubble up the call chain. Instead, you want to return a monad that has error information so that the caller can deal with it more appropriately. This sort of pattern can already be done like so,

public Result DoSomething()
{
    try
    {
		...
        return new Result();
    }
    catch (SomeException e)
    {
		...
        return new FaultedResult();
    }
    catch (SomeOtherException e)
    {
		...
        return new FaultedResult();
    }
    catch (Exception e)
    {
		...
        return new FaultedResult();
    }
}

As you can see it is pretty verbose and you are unable to use this with the expression body method syntax. Let's reimagine that same code from above with what is being proposed using expression body method syntax,

public Result DoSomething() =>
    try
    {
		...
        return new Result();
    }
    catch
    {
    	SomeException e => new FaultedResult(),
    	SomeOtherException e => {
			...
        	return new FaultedResult();
        },
        _ => new FaultedResult()
    }

There is precedence for this expressive pattern both in C# and other languages like Elixir. For reference I provided a link to Elixir docs to show how it is being used in other languages.

https://hexdocs.pm/elixir/try-catch-and-rescue.html

[TahirAhmadov]

I think the exception catching is the next step in this overall direction. The first step would be "expression statements" or whatever they're called. There's a discussion about that.

[full-ing-arr]

I very like it

var res = GetRes() catch GetAlternative();

var res = GetRes() catch Ex when ... => GetAlternative();

var res = GetRes() catch Ex => GetAlternative();

Result SomeExHappened(Exception ex) => ex switch {
  Ex when ... => GetAlternative()
  //raise up the exception when here
};

var res = GetRes() catch SomeExHappened;
or
var res = GetRes() catch myexvar => SomeExHappened(myexvar);

var res = GetRes() catch {
  Ex when ... => ...
  Ex2 when ... => ...
  //raise up the exception when here
};

var res = GetRes() 
  catch GetAlternative() 
    catch GetAlternative2();

var res = GetRes() catch GetAlternative() finaly Smth();

//same
var res = GetRes() catch GetAlternative() finaly Smth() catch GetAlternative2() finaly Smth2();
var res = (   GetRes() catch GetAlternative() finaly Smth()   ) catch GetAlternative2() finaly Smth2();

var res = GetRes() finaly Do();

[Richiban]

There was talk at one point about integrating exceptions into pattern matching, something like

var res = try GetValue() switch
{
   _ => ... // Normal pattern matching
  catch SomeException e => ...
  catch SomeOtherException e => ...
  catch e => ...
}