[Proposal]: Exception-coalescing operator

[zenvin-dev]

Summary

Exception-coalescing operators would introduce syntactic sugar for inlining those try/catch blocks, whose only function is to catch an exception while invoking the right-hand expression of an assignment operator.

Motivation

Currently, there is an entire block of code needed in order to merely assign different values to a variable based on whether an exception occurred:

MyType variable;
try
{
  variable = SomeExpressionThatMayThrow();
}
catch
{
  variable = fallbackValue;
}

The variable needs to be declared, and a try/catch block needs to be introduced.

This is pretty tedious to write, and also annoying to read - more so if it happens to occur several times in a row.
This proposal aims to improve on this, by introducing an operator that makes it possible to shorten this code, similarly to how the null-coalescing operator (??) does for null-checks.

Proposed syntax

There are several way this could be implemented, respectively with different readability and brevity.
The overall syntax would be similar to the null-coalescing operator (??):

op_coalesce_exception
  : identifier EQUAL expression {operator} expression SEMICOLON
  | identifier EQUAL expression {operator} THROW expression SEMICOLON
  ;

In code, that would look something like this:

MyType variable = SomeExpressionThatMayThrow() ?! fallbackValue;

Operator considerations

Ideas for possible operators

Symbol ?!

Advantages:

• Short and readable
• Similar to null-coalescing operator (??), therefore familiar

Disadvantages:

• May be too similar to null-coalescing operator

Repurpose catch keyword

Advantages:

• Verbose and therefore clear
• Could work better with points mentioned in next paragraph

Disadvantages:

• May look confusing
• Longer
• Breaks established convention of similar operators

Further considerations

Typed exception handling

For maximum usability, the operator should support providing information about the exception that occurred.
In order to do this, the syntax could be expanded as follows:

op_coalesce_exception
  : identifier EQUAL expression {operator} expression SEMICOLON
  | identifier EQUAL expression {operator} THROW expression SEMICOLON
  | identifier EQUAL expression {operator} LEFT_PAREN type_name identifier? RIGHT_PAREN expression SEMICOLON
  | identifier EQUAL expression {operator} LEFT_PAREN type_name identifier? RIGHT_PAREN throw expression SEMICOLON
  ;

The identifier of LEFT_PAREN type_name identifier? RIGHT_PAREN should be available to the expression on the right-hand side of the operator.

If the type_name constraint of the handled exception does not match the thrown exception, this also needs to be accounted for.
Two ways of doing this come to mind:

• Throw the exception
• Don't compile if the type of the (final) exception-coalescing operator is narrower than System.Exception

Since chained try/catch blocks will throw if the catch has a too-narrow requirement, the former option would likely represent the expected behaviour.

Chaining

Just like try/catch blocks, exception-coalescing operators should allow chaining in order to account for multiple types of exceptions.
This obviously requires typed exception handling, as described above

[CyrusNajmabadi]

We are unlikely to do this as catching all exceptions like this is definitely an anti pattern.

If you do need this, you could have some exception to help out:

public static T DangerousCatchAll<T>(Func<T> func, T @default)
{
  try
  {
    return func();
  }
  catch
  {
    return @default;
  }
}

Now you could say:

MyType variable = (() => SomeExpressionThatMayThrow()).DangerousCatchAll(fallbackValue);

[CyrusNajmabadi]

Extension methods don't work on method groups (CS0119), anonymous functions or lambda expressions (CS0023) (so SomeExpressionThatMayThrow.DangerousCatchAll(fallbackValue) and similar would not compile).

Let's solve that :)

Besides, try/catch without type constraint also is a catch-all.

Yes. But i'm saying: you should do that as YOUR code. Instead of us embedding this into the language (which we are not likely to do).

[zenvin-dev]

Let's solve that :)

Your edited reply creates the exact error I pointed out before - Operator '.' cannot be applied to operand of type 'lambda expression'.
The only way of doing this I can see, would be calling the utility directly:

DangerousCatchAll(SomeExpressionThatMayThrow, fallbackValue);

Which seems tedious and not very readable.

Instead of us embedding this into the language

But since try/catch blocks without type restrictions on catch are valid syntax, is this behaviour (catch-all) not embedded into the language already?
And adding onto that, why would writing a catch-all try/catch yourself be "doing that as YOUR code" - when utilising an operator (which you also would expressly have to write just as much as an unconstrained try/catch and that fulfils the same function) would not be?

In the end, writing

var test = SomeExpressionThatMayThrow() ?!(NullReferenceException) string.Empty ?! null;

would just be more convenient than

string test;
try
{
  test = SomeExpressionThatMayThrow();
}
catch(NullReferenceException)
{
  test = string.Empty;
}
catch
{
  test = null;
}

while achieving the same thing.
Hence syntactic sugar.

[CyrusNajmabadi]

Your edited reply

Yes. I'd prefer to solve that, rather than using the absence of that feature to motivate creating this one.

[CyrusNajmabadi]

In the end, writing

I would prefer the alternate proposed elsewhere: x switch { catch(...) => ... } which merges catch behavior into switch expressions.

[zenvin-dev]

Your edited reply

Yes. I'd prefer to solve that, rather than using the absence of that feature to motivate creating this one.

Ah, I think I misunderstood you saying "let's solve that", earlier.
Though while extensions for lambdas and method groups would certainly be a cool feature, wouldn't that pattern mandate creating garbage through delegate allocation, just in order to facilitate error handling?