[Proposal]: Evolve catch clause to enable pattern matching for more compact catch-when

[Peter-Juhasz]

Motivation

It is quite a common pattern to narrow down a catch clause based on the Exception properties:

try
{
    // ...
}
catch (OperationCanceledException)
{ }
catch (HttpRequestException ex) when (ex.StatusCode is HttpStatusCode.NotFound)
{ }

Compatibility

The way this proposal may be different from others, and what my original intention is to bring value to the language in the smallest, compatible, incremental way without breaking the original try-catch-finally statement structure or introducing different syntaxes other than what we already have.

try-catch statement, not expression

Also, this proposal focuses on improving the try-catch statement, at the statement level, so it can be used in existing control flow, and not at the expression level, like the switch expression.

Description

The catch clause is already pattern-like, because it can behave either as a type filter, or a type filter and a declaration as well.

The when clause was quite useful on its own, but today in many cases these two clauses could be merged into a more powerful catch clause, where not only declaration is allowed, but a pattern:

try 
{
    // ...
}
catch (OperationCanceledException)
{ }
catch (HttpRequestException { StatusCode: HttpStatusCode.NotFound } ex)
{
    // `ex` is available here
}

So, this example is equivalent to the first one, but in a more compact form using a pattern in the catch clause without a when clause.

The when clause could still remain for narrowing down the filter further if non-constant evaluation is necessary.

Detailed design

In language specification: exception_specifier inside a specific_catch_clause could be replaced to a pattern/declaration_pattern.

  specific_catch_clause
      : 'catch' exception_specifier exception_filter? block
      | 'catch' exception_filter block
      ;

  exception_specifier
-     : '(' type identifier? ')'
+     : '(' (type identifier? | pattern) ')'
      ;

(Based on the Patterns section in the documentation, I'm not sure which is the best choice, but I hope you get the idea.)

Originally posted by @Peter-Juhasz in #8490

[333fred]

As per our readme, all new proposals not championed by a member of the language design team should be started as discussions.

[333fred]

And of course, this is a duplicate of #8490, which I did not notice at first. Closing.