[Proposal/Discussion] Catch/Exception Patterns

[HaloFour]

Based on the various proposals around expression-based exception handling and a comment made by @CyrusNajmabadi I'd like to toss catch patterns into the discussion. I'll only flesh them out a little bit (throwing spaghetti against the wall) and open the floor to further input.

I propose the addition of catch patterns for pattern matching. These patterns would apply to the switch statement and potential future switch/match expression by using the catch keyword either in place of or in addition to the case keyword, e.g.:

switch (SomeExpression()) {
    case Result result: return result;
    catch Exception _: return Result.Empty;
    // or
    case catch Exception _: return Result.Empty;
}

When a catch pattern is included in the list of patterns the expression used in the switch statement is implicitly wrapped in a try statement. There can be any number of catch patterns, each followed by a pattern that is matched against the actual exception thrown by the expression.

switch (SomeExpression()) {
    case Result result: return result;
    catch SomeException exception: // type-switch
        return Result.Empty;
    catch OtherException exception when exception.Message == "oops": // type-switch with guard
        return Result.Empty;
    catch AnotherException { ErrNumber is 123, Message is var message }: // recursive property pattern 
        return Result.Empty;
    catch YetAnotherException _: // type-switch with discard
        return Result.Empty;
    catch _: // catch-all    
        return Result.Empty;
}

The catch patterns are emitted as separate catch blocks that catch the appropriate exception in lexical order using exception filters to enforce additional pattern matching. That way any unmatched exceptions remain unhandled and thrown:

switch (SomeExpression()) {
    case Result result: return result;
    catch SomeException _: return Result.Empty;
    catch OtherException exception when exception.Message == "oops": return Result.Empty;
}

// equivalent to (assuming SomeExpression returns object)
object obj;
try {
    obj = this.SomeExpression(); 
}
catch (SomeException) {
    return Result.Empty;
}
catch (OtherException exception when exception.Message == "oops") {
    return Result.Empty;
}
Result result;
if (obj != null && (result = (obj as Result)) != null) {
    return result;
}

Open Questions (non-exhaustive, will add more from comments):

1. Philosophical issues with potential "exception swallowing".
2. Concerns about not being able to immediately discern that exception handling is going on? Should try be crammed in there somewhere? switch (try SomeExpression())?
3. Behavior of default or case var _?
   • In my opinion that should only apply to the return value of the expression and not any thrown exceptions, but open for discussion.
4. Support with the is operator? I can't imagine how that would work but it would be asymmetric if it didn't.
5. What about a finally "pattern" that always gets executed once execution leaves the switch block?
6. Scope of out declaration variables or pattern variables from the expression in the switch statement?
   • In my opinion those variables would be in scope within the catch statements, however they would not be definitely assigned.

[YotaXP]

Should there be a finally case as well?

Also, there could be a little confusion with scope here.

switch (SomeMethod(out var o)) {
    default: return o; // Fine
    catch _: return o; // 'o' does not exist here, despite being inside the braces
}

Edit: Actually, does o exist inside that default case? If it expands into the example code you made above, I would think not.

[HaloFour]

@YotaXP

Good questions, I've added them to the list.

Regarding the scope of declaration/pattern variables, I would think that those variables would be in scope but they would not be definitely assigned. Think of your statement being interpreted as follows:

object o, $result;
try {
    $result = SomeMethod(out o);
}
catch {
    return o; // error CS0165: Use of unassigned local variable 'o'
}
return o; // fine

[iam3yal]

Philosophical issues with potential "exception swallowing".

In my opinion the language doesn't need to babysit developers so it should be up to the developer much like it is today.

What about a finally "pattern" that always gets executed once execution leaves the switch block?

Could be cool to have something like this:

switch (SomeExpression()) {
    case Result result: ...
    catch Exception _: ...
    finally IDisposable d when d != null: d.Dispose();
}

[qrli]

I don't think finally is necessary in this case. finally is about resource life-cycle, and the typical c# way for that is using. So

using (var exp = SomeExpression())
{
    switch (exp) {
        case Result result: ...
        catch Exception _: ...
    }
}

For expression form, you'd use the result anyway, so it has to be disposed later:

using (var result = SomeExpression() match (
        case Result result: ...
        catch Exception _: ...
    ))
{
    UseIt(result);
}

[orthoxerox]

@eyalsk that's like proposing to remove safety labels off everything to ensure only smart people survive past puberty, C# has always been about "the pit of success", where the most obvious solution should be the best one. Swallowing exceptions should have always been harder or at least uglier than handling them properly.

[DavidArno]

@orthoxerox,

C# has always been about "the pit of success", where the most obvious solution should be the best one. Swallowing exceptions should have always been harder or at least uglier than handling them properly.

I dispute your claim that "C# has always been about "the pit of success"". Being wise after the event and all that, but many C# features are the opposite. And, as the team have shown with recent new features, consistency with existing language paradigms wins out over "pit of success" even today.

As such, assuming a feature similar to this one were adopted, it is likely that the syntax would favour consistency with existing catches (which makes it easier to swallow all exceptions than to handle them properly) over making exception swallowing hard.

[HaloFour]

The finally clause isn't always about resource cleanup, but I do agree that it doesn't quite feel right here, especially in the context of switch as an expression. If you need a finally clause you can always fall back to wrapping the entire statement/expression in a try/finally (or using if you're actually dealing with IDisposable).

I do agree with the notion that the language should try to guide developers towards "doing the right thing" by making that "right thing" easier. Patterns which are considered abusive shouldn't be encouraged by introducing shorthand, especially if that makes it easier than following the best practices. However, those patterns/practices are always evolving and often line up with philosophical/paradigmic arguments regarding language design. Hence @DavidArno always complaining that C# isn't a pure immutable functional language. (Sorry, had to snipe back. 😉)

That said, the open question here is whether or not this feature might promote abuse by those who are less likely to understand the ramifications of that abuse, and whether or not that matters.

[bondsbw]

The main weirdness here is that there is no try (no Yoda pun intended).

That's not a huge problem. But before I read the full proposal, I wasn't sure what is in scope for exception handling. Is it:

1. just the expression of the switch statement?
2. all of the case clauses (and their blocks) before the catch?
3. all of the case clauses regardless of where the catch is?
4. some combination of the above?

Looks like 1 is the answer if I read the proposal correctly.

But then

5. What about a finally "pattern" that always gets executed once execution leaves the switch block?

seems inconsistent, having a different scope than the catch clauses.

[HaloFour]

@bondsbw

But before I read the full proposal, I wasn't sure what is in scope for exception handling.

I had intended that the scope of the exception handling would only be on the switch expression, so it would not apply to further exceptions thrown in any of the case sections. I can see how that might not be immediately obvious.

As for the inclusion of a try keyword, I agree that would make the intent clearer and might even be able to clarify the scope of the expression handling but I haven't found a combination that I've found visually pleasing. I'm not aware of a language that would allow mixing pattern matching and exception handling patterns into the same construct from which to draw inspiration.

[iam3yal]

@orthoxerox

C# has always been about "the pit of success"

Well, I don't know about always I mean it's really easy to swallow exceptions hence what you said but I really think that the "the pit of success" is more of an slogan than a reason against it.

Swallowing exceptions should have always been harder or at least uglier than handling them properly.

Yes, maybe it should have been.

[iam3yal]

@qrli

I don't think finally is necessary in this case. finally is about resource life-cycle, and the typical c# way for that is using.

It's like saying I don't think that catching exceptions in a switch statement or match expression is necessary; try/catch is about catching exceptions whereas switch/match is about branching and the typical C# way to do either of them is not to have this feature at all but here we are.

[iam3yal]

@HaloFour

That said, the open question here is whether or not this feature might promote abuse by those who are less likely to understand the ramifications of that abuse, and whether or not that matters.

Well, I'm trying to understand why a feature which is mostly syntactic sugar should prevent developers from swallowing? I mean I'm not against it, I wouldn't mind it either way but if the developer already decided about it why the language needs to stop him when he can just use another syntax and get it done? it seems like we started with C# is safe and now we're past the point where C# puts handcuffs, at least this is how it feels.

[HaloFour]

@eyalsk

That's largely in comparison to the other try expressions which appear to make it particularly simple to swallow an exception, sometimes by not exposing the exception at all. This proposal doesn't seem to make it any harder or easier to swallow exceptions than normal try/catch statements.

[qrli]

@eyalsk

It's like saying I don't think that catching exceptions in a switch statement or match expression is necessary; try/catch is about catching exceptions whereas switch/match is about branching and the typical C# way to do either of them is not to have this feature at all but here we are.

I don't think that way. Exception handling is clearly a case and branching, so put it in switch is logical and useful. In contrast, adding finally to switch to do disposing is more (duplicated) code in the low-level way.

[iam3yal]

@qrli Well, sure but then I can say that finally is a different kind of branching.

adding finally to switch to do disposing is more (duplicated) code in the low-level way.

Can you elaborate? how is it more (duplicated) code? I mean since when we care how much code goes into the implementation of a feature and why is it even relevant to the discussion?

The only real argument against it in my opinion is "It doesn't feel right" which I can understand why it wouldn't.

[qrli]

@eyalsk As in your example code

    finally IDisposable d when d != null: d.Dispose();

You just implemented the part of what using auto-generates. Yes, it is not much code to write. But you have to write it every time.

[iam3yal]

@qrli Still can't get your point and I'm not sure why we discuss implementation details, it's just like taking the proposed example and say that this will get lowered into a try/catch block and a switch statement, great but I really don't think that this helps in the argument against it so can we please discuss actual scenarios, concerns and why people think others will abuse it?

[HaloFour]

My two qualms with the concept of a finally in this is that it would lead to two cases being executed instead of one, and that finally doesn't really represent a pattern against any value.

[iam3yal]

@HaloFour Fair enough, these are good points. :)

[gulshan]

I have a few observations-

• As the success case(s) is part of the "expression", it has to have a "type" it evaluates to. And as C# doesn't have unit type or cannot return void type, many cases will not be covered with this proposal without some kind of code-bending.
• As being part of same expression, the fail or catch cases should evaluate to the same type of the success case(s) and not the type of the expression being matched to, which may not be convenient.
• I personally do not like mixing catches and cases. This is not an usual branching operation. Cases are matched with the evaluated value of the expression while catches are matched against an exception thrown while evaluating the expression. F# handle .net exception with try...with syntax while there is a separate match...with syntax for matching values.
• With this syntax, am I free to mix cases and catches in the ordering? Or should a group be together always? Or catches should always be at the end?
• Usually there is one success case for try...catch syntax with a bigger body, which can be considered as the main flow of a program. And exceptions are the corner cases(literally exceptions) in the flow. I like to visualize this in the code. So, I like the exception handling code is indented while the main/normal flow is not. This syntax is contrary to that.
• Current try-catch gets a bit ugly for nested situations. To keep the code simple and readable, multiple try blocks are often consolidated to one making catches more general instead of targeting one exception throwing statement. This proposed syntax does not make those situations any better. In my opinion, nesting will look worse than current try...catch with this syntax.

Most of this glitches can be solved by returning the success value out of the try/match expression and proceed. But then, why would don't we just design the syntax that way- where only catches are handled and normal case is passed on. I think my proposal in #980 tries to do that.

Regarding exception handling in general, I think pre-condition failures should not be exceptions and should have separate way of handling. That may be a Result type. Or the compiler can ensure the preconditions are met at the call-site, just like it currently does for the types and will be doing for the nulls in future. Exceptions should only be thrown when an error occurred during the execution/computation of an statement/expression. And languages should not make it easy to "swallow-all-the-exceptions". At least swallow-all can have a explicit different syntax like panic when it is needed (top-level handlers). But it is probably too late for .net ecosystem to embrace that or any new error-handling philosophy.

[gafter]

I'm wondering if this proposed construct would actually be widely used to simplify the kinds of code that people have to write today. I'm having a hard time finding many places in my code where I'd use this, and that makes me question its utility as a language addition. Perhaps you could point to places, e.g. in Roslyn, where this would be just what is needed.

[HaloFour]

@gafter

Seemingly enough for @CyrusNajmabadi to originally suggest such a thing and for @jaredpar and @KrzysztofCwalina to have already prototyped out simpler try expressions due to annoyances in dealing with it in Roslyn/VS/etc.

I'm not entirely sold on this either, but I thought it was worth some discussion. The topic of the verbosity and limitations of try statements have generated quite a few issues on this repo. What I like about this particular approach is that while it allows for the seamless use of exception handling within an expression it doesn't do so in a manner that implicitly encourages exception swallowing, at least no more than try statements today.

[HaloFour]

Looks like Java is exploring something like this: https://inside.java/2023/12/15/switch-case-effect/

[333fred]

I think I would be willing to champion this.

[dersia]

this would only be implemented for switch expressions, not for switch statements, right? I can see issues with implementing this for switch statements.

for switch expressions this looks like a good feature, espacially once we have expression bodies.

[333fred]

I don't see why we would limit it to switch expressions.

[jaredpar]

I used to really like the idea of having try <expr> catch <expr> as an expression form in C#. The switch proposal here is a bit more verbose than I'd like but it will still be more palatable than try blocks.

[DavidArno]

I don't see why we would limit it to switch expressions.

Being able to express things like this genuinely appeals to me, so I'm in favour of not limiting it:

int ParseIntOrDefault(object maybeNumber) 
    => Int32.Parse(maybeNumber) is not catch ArgumentException and not catch FormatException and var intValue 
        ? intValue 
        : 0;

[IS4Code]

I would enjoy this feature, but I feel that there is definitely a need for visual indication that try is happening. Using a normal switch block for now (I don't see why this feature would have to be limited to switch expressions only):

switch(expr)
{
    case int i: ... break;
    case string s: ... break;
    case float f: ... break;
    ...
    ...
    ...
    case catch Exception e: ... break;
}

The information whether expr is "throwing" or "non-throwing" could be arbitrarily far below its line, but it is a very important information for mentally validating correct code. In other words, removing the case catch line would suddenly cause another line to be throwing. Sure, the same could happen with a normal catch block, but at least you have the try there to know that something special is happening. I don't think there is any similar feature in the language where such a disconnect/detachment could happen, so it might be very surprising.

Luckily this is easy to fix:

switch(try expr)
{
    case int i: ... break;
    case string s: ... break;
    case float f: ... break;
    case catch Exception e: ... break;
}

A try <expr> is a new kind of expression that can be mentally thought of as wrapping a result or an exception in a discriminated union, with the important difference being that if the exception is not handled, it is thrown as usual. This is just a mental model of course, since a normal try/catch is what would be happening under the hood here. A catch pattern is a normal pattern (wrapping a pattern on Exception) that is valid only when matched against a try expression.

This being a normal pattern makes it convenient in other places too:

bool IsSomethingInvalid() => try DoSomething() is catch InvalidOperationException; 

---

Perhaps in the future, there could be a concrete type or a different variety of result-like or optional-like types that you could use to materialize the result of a try expression:

Result<string> result = try GetStringOrThrow();
return result.Success ? result.Value : result.Exception.Message;

There are actually such types right now, Task for example. This could solve one issue I frequently had:

Task<string> GetStringTask()
{
    return try GetStringOrThrow();
}

Without a try expression being materializable as Task, I would either have to do the usual chore of Task.FromResult and Task.FromException to properly wrap it, or add async but having to suppress the warning that there is no await and live with it for the rest of my life.

There have been other proposals about lightweight exceptions/error codes, so this could really nicely prepare the ground for them too.

[HaloFour]

@dersia

What does happen here if there is an Exception? is ProductCode set?

No, s would not be definitely assigned. That's already the case with fall-through involving patterns, adding exceptions into the mix doesn't change that.

switch(expr) {
    case int i:
    case string s:
        setProductCode(s); // error CS0165: Use of unassigned local variable 's'
        break;
}

[Richiban]

I don't see it in this discussion here, but do remember this syntax being proposed somewhere:

try switch(expr)
{
    case ...
}

I see it as syntactically unambiguous and I think it reads nicely. It has the advantage of immediately indicating that the switch statement/expression handles exceptions so I quite like it; I'm currently just trying to work out if I'm guilty of https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html

[IS4Code]

@Richiban To me this reads that the whole switch, including the individual cases, is subject to the try. If this is to work in any general pattern-matching situation, the only place where it could be indicated is the pattern and the tested expression.

[Richiban]

@IS4Code I get where you're coming from; the reason I don't like switch (try expr) is because (I feel) everything in the parens should be a normal C# expression, and try expr is not a normal expression.

I think I may be the first in this repo to suggest taking a left out of Erlang's book, but in Erlang the try construct has built-in support for pattern matching for the returned value, as well as for the errors.

An equivalent in C# might be to allow this syntax:

string r = 
  try(expr) 
  {
      "Foo" => $"Bar",
      string s => s,
      catch FormatException => $"Wrong Format",
      catch Exception ex => ex.Message
  };

[HaloFour]

To match C# syntax you'd probably want the try "operator" to be post-fix, like switch is, when it's an expression.

string r = 
  expr try
  {
      "Foo" => $"Bar",
      string s => s,
      catch FormatException => $"Wrong Format",
      catch Exception ex => ex.Message
  };

But, at that point, is there a lot of value to having try at all? It would seemingly only exist to make this form of match stand out.