Exploring future of try expression

[gulshan]

There was a discussion regarding what try expressions may look like two years ago. Since then, a change has been made in C# language- how match or switch expression looks like. With the chosen syntax of switch expression, most of the then proposals of try expression syntax are outdated now. I am not proposing a single try expression syntax here. Rather I am trying to explore different paths try expression can take in future for C#. I can basically imagine four syntaxes for try expression. To describe them, I want to use the following snippet with current try-catch syntax, which then will be translated to syntax of the respective proposals. Given a method, User Authenticate(Credential credential) which may throw ValidationException or AuthenticationException-

try
{
    var user = Authenticate(cred);
    user.DoStuff();
}
catch (ValidationException e)
{
    Logger.LogException("Invalid credential", e);
}
catch (AuthenticationException e)
{
    Logger.LogException("Not authentic credential", e);
}

try expression

try expression evaluated to a Result object combining success and exception cases. Then switch expression can be applied on the result object. Given example will be-

var userResult = try Authenticate(cred);
var user = userResult switch {
    User user => user,
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
};
user?.DoStuff();

Or it can be-

var userResult = try Authenticate(cred);
if(userResult is User user)
{
    user.DoStuff();
}
else
{
    userResult switch {
        ValidationException e => Logger.LogException("Invalid credential", e),
        AuthenticationException e => Logger.LogException("Inauthentic credential", e),
    };
}

Or it can be-

// assuming all arms are evaluated to void
try Authenticate(cred) switch {
    User user => user.DoStuff(),
    ValidationException e => Logger.LogException("Invalid credential", e),
    AuthenticationException e => Logger.LogException("Inauthentic credential", e),
};

Notice calling LogExceptionAndReturnNull method in some cases, as all arms of switch expression have to return value of same type.

Pros:

• Result type, for those who like it.

Cons:

• Result type, for those who dislike it. It is a kind of "swallow all" pattern, not goes well with C# style I think.

try ... switch expression

The try ... switch expression will be extending the current switch syntax to catch and handle exception cases, when input is given with a try. Given example will be-

var user = try Authenticate(cred) switch {
    User user => user,
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
};
user?.DoStuff();

Or it can be-

// assuming all arms are evaluated to void
try Authenticate(cred) switch {
    User user => user.DoStuff(),
    ValidationException e => Logger.LogException("Invalid credential", e),
    AuthenticationException e => Logger.LogException("Inauthentic credential", e),
};

LogExceptionAndReturnNull has been used here also.

Pros:

• Unlike previous one, it is not a "swallow all" pattern- unhandled exceptions are thrown, unless decided that the default or _ arm/case will also swallow all other exception.
• Good when user is trying to do simple and similar(of same return type) operations for all success and exception cases.

Cons:

• No syntactic distinction among success and exception cases.
• All arms of switch expression have to return value of same type, which can be irritating.
• May be confusing regarding what default or _ case is doing with exceptions not already handled.

try ... catch expression 1

Here catch part will use same syntax as current switch, but will catch and handle only exception cases. Unhandled exceptions will be thrown. The result in the success case can be handled in any way necessary. Given example will be-

var user = try Authenticate(cred) catch {
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
};
user?.DoStuff();

Or it can be-

try Authenticate(cred) catch {
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
}?.DoStuff();

LogExceptionAndReturnNull has been used here as well.

Pros:

• Success and exception cases are clearly separated.

Cons:

• All arms of catch part have to return a default value of same type, which can be irritating.

try ... catch expression 2

This is same as the previous one, except catch parts does not have to (or cannot) supply a default value. For all handled exceptions, the default value is simply null. The ?? operator can be used to provide other default values. Like previous one, unhandled exceptions will be thrown. So here arms/cases of the catch do not contribute to the type of resultant expression. Given example will be-

var user = try Authenticate(cred) catch {
    ValidationException e => Logger.LogException("Invalid credential", e),
    AuthenticationException e => Logger.LogException("Inauthentic credential", e),
};
user?.DoStuff();

Or it can be-

try Authenticate(cred) catch {
    ValidationException e => Logger.LogException("Invalid credential", e),
    AuthenticationException e => Logger.LogException("Inauthentic credential", e),
}?.DoStuff();

Pros:

• Success and exception cases are clearly separated.
• Most concise syntax in my opinion.

Cons:

• Cannot have separate default values for different exceptions.
• There may be confusion regarding catch cases not contributing to the result.

For last two proposals, I don't like allowing a swallow-all _ or default case. But someone can be for it. Personally I like the last syntax. Let's discuss which one do you like and why. Did I miss pros or cons of any syntax? And also, can there be any other syntax for try expression?

Some related issues and discussions can be found in #1019 and other issues it referenced.

[reflectronic]

Some of this sounds similar to Midori's dataflow-oriented syntax sugar around try/catch.

[gulshan]

BTW, the initial version of the third syntax was proposed by @Pxtl here- #980 (comment)

[DanFTRX]

None of the proposed syntaxes are functionally equivalent to your current syntax example.. The example has the user.DoStuff() in the try catch, the rest call it on the result of the try catch.

[uygary]

I don't think any of the try expression or try ... switch expression approaches would really work. They cannot possibly handle something like this:

FooException GetMappedException(Bar barResult)
{
    /* Do stuff... */
}
FooException mappedException;
try
{
    mappedException = GetMappedException(errorResult);
}
catch(FooException ex)
{
    /* Do stuff... */
}

The try ... catch expression variants could work though.

[Thaina]

I prefer option 1 because it would be almost the same as switch expression

Another option. Maybe switch expression should support catch and finally and we could mixing case and catch and finally in the same place

var user = Authenticate(cred) switch {
    case {} u => u,
    catch ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    catch AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
    finally => ReleaseSomething()
}

[Hosch250]

I like the concept, but I'm just a bit curious what the type of user would be? Would it be like a Maybe<T> type? Or object? Or dynamic (I don't like this option because it doesn't provide any type hints)? Because I don't think C# at the moment would allow you to swap between any number of types for a single value.

[Thaina]

@Hosch250 C# at the moment can use switch syntax to check the type

object obj = DoSomeThing();
switch(obj)
{
    case int i: return "number : " + i.ToString();
    case long l: return "number : " + l.ToString();
    case float f: return "number : " + f.ToString();
    case string s: return "string : " + s.ToString();
}

[uygary]

@Thaina I believe @Hosch250 was referring to the type that would be inferred for user, and that would be whatever type Authenticate returns. In case of an exception, it would be either assigned whatever FooBarAndReturn() returns, or defaulted in the case of FooBar() (ie. null for a reference type.)

I can't say that I'm a big fan of the idea myself, but I can see why some might find this syntax useful.

[Hosch250]

Ah, it was in the proposal, I just missed it. I was thinking about the following structure:

var userResult = try Authenticate(cred);
var user = userResult switch {
    User user => user,
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
};
user?.DoStuff();

I missed where it said the pros/cons were the use of a Result type.

[MV10]

I think @DanFTRX raises a great point, and in general this seems to create more problems than it solves. In fact, I'm not actually sure what problem it is meant to solve: I can't think of a use-case for what amounts to conflating assignment and non-local, non-block-level exception handling.

Crucially, what happens to unhandled exceptions? Should it just float around, quietly put on hold in this Result object until the code happens to call this new switch syntax? Say the Result is passed elsewhere. Should an unhandled exception throw again if the Result exception is evaluated more than once?

How does this work if you need a finally-style cleanup?

In the unlikely event somebody has a real need for this, you can handle it yourself by returning a tuple like (UserInfo info, Exception exception). Then the second if-else example works without any new syntax (just a little additional work inside the target method). But that seems like considerably more effort and complexity-coupling than the current try-catch syntax.

[Pxtl]

Personally, I strongly want this. I often find the absence of this feature causes the constant repetition of the variable name in declare varname => try => set varname value. If a method throws an exception and I want to handle it but still return an object to the caller, this is needed.

Definitely prefer try ... catch expression 1. It's an expression - expressions should return something. The non-return syntax seems to defeat the purpose.

edit: small correction in try ... catch expression 1: There is one case where they shouldn't have to return: where they throw. Throw should be an acceptable alternative to return. Because of course, a logical use of the try...catch expression would be to wrap exceptions. Because, of course, that doesn't violate return type expectations.

[janis-veinbergs]

I also feel a need for try expression and agree to @Pxtl
I also agree to @MV10 regarding result type - it is a paradigm shift and shouldn't mess with try..catch expressions.

I really long the days I do not have to scope some variable outside try/catch block, because I want localized try/catch blocks so further statements get their own exception handlers, but I want to reuse result from the previous try/catch. In F# world this is called try..with expression.

There are tons of proposals about single line try/catch statements, expressions and whatnot - most of them closed because they encourage swallowing exception. However this discussion/proposal could actually invite handling the exceptions in a stronger way than before: try without catch or without explicit discard pattern should do _ => throw or could be a compiler error. And the shortest way to swallow exception would be: var user = try Authenticate(cred) catch { _ => default }

I believe implicitly throwing if discard pattern case not provided is acceptable as currently functions with return value can be escaped the same way - if exception is thrown or one doesn't catch an exception.

Regarding finally

The only issue is that I cannot come up with whether finally is needed here. An expression implies single... expression after try keyword, not multiple statements. Do you (me) really want to mess with stuff done before you wrote that try keyword and do something with it within finally?

var user = try Authenticate(cred) catch {
    ValidationException e => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    AuthenticationException e => Logger.LogExceptionAndReturnNull("Inauthentic credential", e),
    _ => throw; //this is just catch-all Exception. If omitted, either `throw`
                      // Equivalent to (Exception) => throw
                      // If i need exception: (Exception ex) => { log.Fatal(ex); throw }
} finally { 

};
user?.DoStuff();

Perhaps the finally case is actually the discard pattern case as we are used to write it in pattern matching when all possible cases must be matched: _ => .... But it is not a real finally - ValidationException maybe is already processed and that implies discard pattern _ case will not be invoked.

Questions pop up: What is finally? We have already returned a value, what do we do here? Is it appropriate to invite users to cleanup some resources that are outside of this particular expression and invite side-effects? The finally has no return value and is kind of a thing from statement world and not expression world - doing a statement after expression in this way feels wrong.

Someone help figure out if finally would actually be useful in a fully-covered try..catch expression. I believe try..finally should be a different language construct just as it is in F# - so you may want to:

try {
  try expr catch {
    pattern1 => expression2,
    pattern2 => expression3,
  }
} finally {
  //now we can do finally
}

But that would probably imply that try..finally would have to allow statements and not expressions, thus we come to conclusion that... we already have that since C# has roamed the earth back in 2002 :)

try {
  stmt;
} finally {

}

Point being made is finally shouldn't be messed into try..catch. Except maybe if one wants to have a return value from finally like in F# - that would be a different discussion then.

Exception filters

I believe when should also be supported:

var user = try Authenticate(cred) catch {
    (ValidationException e) when (e.ErrorCode == 0x1234) => Logger.LogExceptionAndReturnNull("Invalid credential", e),
    _ => throw
}

Conclusion

Lets keep grinding this idea until it shines

An example. I want to be able write something along the lines to ensure I got only a single item and if not, make a much user-friendlyer error message than whatever LINQ would spit out for Single() method. Regarding this particular example: someone would say: dork, use FirstOrDefault - no, then I will silently miss the fact that I didn't had my data right in the first place and will still have to check with if if I don't have empty result.

var someResult = try getResults(someCollectionQuery).Single() catch {
   (InvalidOperationException ex) => throw new InvalidOperationException($"Single unique entry not found for query {someCollectionQuery}", ex);
}
doSomething(someCollection);

Instead of:

var someResult;
try {
      someResult = getResults(someCollectionQuery).Single();
} catch (InvalidOperationException ex) {
      throw new InvalidOperationException($"Single unique entry not found for query {someCollectionQuery}", ex);
}
doSomething(someCollection);

Maybe the reason we rarely have nice and precise error messages, because the language doesn't give us a convenient way to make them be so?

[HaloFour]

IMO, if a try expression were to be considered, I'd like it to take into account future work on DUs and the possibility of a language-blessed Result<T> DU. The expression try <expr> could then be shorthand for wrapping the expression in a Result<T> which would make it easy to use in normal pattern matching:

var someResult = try getResults(someCollectionQuery).Single() switch {
    Success(var value) => value,
    Failure(InvalidOperationException ex) => throw new InvalidOperationException($"Single unique entry not found for query {someCollectionQuery}", ex);
}
doSomething(someCollection);

Although I would prefer a better use case as honestly there are much better ways to do that then to catch/rewrap an exception.

[MV10]

I'm still not clear what problem is being solved by any of this.

Or, for that matter, why these kinds of things are entertained, when other ideas are tossed because C# supposedly follows a tradition of C-like syntax, which this and already-implemented things like switch expressions clearly are not.

But mostly I'm struggling to see the value-add...

[HaloFour]

C# has a heritage of C-like syntax, but that doesn't mean that it's stuck with C-like grammar for all time, or that features from other languages cannot be entertained.

[janis-veinbergs]

C# supposedly was born out of C, but now follows in F# language path, making it hybrid and unique.

Anyways, I looked around my try statements to understand my frustrations.

It doesn't apply to statements, where there are multiple lines of something - no frustrations there.

It mostly applies to single line statements where I want to re-throw exception with finer error message within a scope where can I access all the relevant and interesting information. My frustration always comes that I have to declare variable beforehand, out ouf try scope, because afterwards I'm gonna be using it. So it is like going from 6 lines of code to 3. And it just flows better in my mind when I think about the try..catch expression solution.

At the same time I noticed that it is not really all over the place, bur rather a considerable minority of try/catch statements. I was disappointed with this finding :) When I try to find other (my usecases to try..catch expression - when I get at least one other change sans call to some method - it doesn't save me much.

Other user proposal - discard

Reading other proposals, users wanted a convenient way to discard result - which is discouraged, but valid use-case when made explicit. But even in this case, I checked my code, it again boils down to the story of inconvenient declarations and having them type explicitly and cannot use var

//Old way
SomeType preImage = null;
SomeType postImage = null;
// If one of these fails, it's ok. If both fail, we have a problem.
try { preImage = func1(); } catch { } 
try { postImage = func2(); } catch { }
if (preImage == null && postImage == null) { throw new InvalidPluginExecutionException("Cannot get neither pre or post Images. Cannot continue!"); }

//New way
// If one of these fails, it's ok. If both fail, we have a problem.
var preImage = try func1() catch { _ => null } 
var postImage = try func2() catch { _ => null }
if (preImage == null && postImage == null) { throw new InvalidPluginExecutionException("Cannot get neither pre or post Images. Cannot continue!"); }

Other user proposal - log & discard

Another point in proposals I was reading: people want to log and discard result (well, return null or default). This actually doesn't make it any more convenient, as it would imply result must be returend explicitly, thus you still end up typing extra curly braces and type return statement. The proposals were much shorter, like var resut = func() !! (Exception ex) => log(x) but they were flawed in other areas - silently returning null value, discouraging exception handling or the like. Anyways, I imagined what would log the occurrance and return null would look like. And looks like it only gets rid of declaration.

//Old
SomeType result = null;
try {
   func()
} catch (Exception ex) { log(ex); return null; }

//New
var result = try func() catch {
   (Exception ex) => { log(ex); return null; }
} 

//Maybe I don't need curly braces for catch too if I only process 1 exception?
var result = try func() catch (Exception ex) => { log(ex); return null; }

//Perhaps we can even replace `Exception` with `var` as `var` pattern matches any expression... like `Exception` catches any exception:
var result = try func() catch (var ex) => { log(ex); return null; }

C# successfully tackles this empty declaration problem before if statement and whatnot with out variables and pattern matching type tests - so that may also be considered saving a single line of code either by declaring variable inline or saving a cast. I thought this proposal follows those features, which enables variable definitions and checks within if statement.

Conclusion

Looks like for me it only boils down to:

• No need to write empty declaration
• Can use var keyword
• Can type less curly braces.
• Hadn't come up for my use case, but maybe for others - try within if statement

Not a huge win compared to C# latest goodies, so perhaps this proposal is in that same idea category as out variables and type tests. Whether it is worth the consideration is up to C# team :)

This discussion helped myself understand what I don't like about try/catch and it ain't THAT bad.

HaloFour

@HaloFour thanks for your answer too - for purposes of growing, maybe you can share what would be the better ways to rethrow exception with more appropriate error messages?

I actually did come up with this construct for myself and am quite satisfied. But it was possible because in this particular case, I can check the condition myself and use methods that won't throw exception and works today:

var someResult = getResults(someCollectionQuery) switch {
      [var first] => first,
      [] => throw new InvalidOperationException($"No entry found for query {someCollectionQuery}, expected 1"),
      [_, _, ..] => throw new InvalidOperationException($"More than 1 entry found for query {someCollectionQuery}, expected 1"),
};

[HaloFour]

for purposes of growing, maybe you can share what would be the better ways to rethrow exception with more appropriate error messages?

That just feels very Java-y to me, forced due to checked exceptions rather than because it's a good idea. In most cases I think it's fine to let the exception bubble out. In some cases it makes sense at a library API boundary, but that's the "exception", not the norm, to the extent that I don't think the language needs to optimize syntax for it. For the use case you specified, I wouldn't rely on LINQ throwing an exception to determine if the collection was empty, there are plenty of much less expensive ways to do that and most other forms of input validation.

DUs seem to be on the list of things the language team wants to add to C#, and a commonly brought up use case is Result<T>, so to me it makes sense to have try expressions bridge between the world of thrown exceptions and monads. DUs are going to support pattern matching and destructuring anyway, so IMO it makes sense to build that form of exception handling on top of it, allowing the language to emit more optimized IL where appropriate.

[Rekkonnect]

I believe the purpose of a try expression would be to simplify the ceremonial code around trying the execution of a simple expression, and handling exceptions at a fundamental basis, and quickly using that result of the execution, or ignoring it if failed.

Otherwise, should things get more complex, the standard try statement is always preferred, as it's cleaner and clearer of purpose.

To demonstrate, say you want one database operation to be performed, and log the exception if thrown, without caring about its type because it's unexpected. The syntax I'd strive for is something like this:

var result =
    try ExecuteOperation(args)
    catch e => logger.ErrorException(e);

The above pretty conveniently conveys the meaning for a simple invocation and the logging of an exception that we don't evaluate after being thrown.

Now, for something that would evaluate the exception, a switch-like syntax would be appropriate after the catch keyword, like this:

var result =
    try ExecuteOperation(args)
    catch
    {
        ArgumentException or
        NotSupportedException => throw,
        Exception e => logger.ErrorException(e)
    };

As for the final result of the expression, if the tried expression succeeds, it would be the result of that expression. Otherwise, if we roll into the catch area, the default value of the target type is returned. However, it would be ideal to customize that, so something like the following could suit:

var result =
    try ExecuteOperation(args)
    catch e
    {
        ArgumentException or
        NotSupportedException => throw,
        InvalidOperationException ioe =>
        {
            return ExceptionResult.Invalid(ioe);
        },
        _ => logger.ErrorException(e),
    }
    into new ExceptionResult(e);

The above example would return new ExceptionResult(e) if an exception was caught, except for AE, NSE and IOE, where in the first two, the original exception would be rethrown and no result would be returned, and for IOE, ExceptionResult.Invalid(ioe) would be returned. Expressions in arms would need to return void in order to fall back to the into case. Otherwise, the direct result is returned.

That's about as far as I'd personally go with such an expression, before starting to think hard how to write it beautifully.

[MV10]

I see the appeal of the first example, although in production-quality code I think one-offs are somewhat rare.

[HaloFour]

I would expect those examples to be compiler errors as the branch with logger.ErrorException does not produce a value.

Edit: I see you mention this:

the default value of the target type is returned.

I would disagree strongly with this notion, an explicit value should always be expected if the catch were to fall out without throwing another exception.

[gulshan]

I have developed some new perspectives on exception handling in C#, or languages with Exception in general. I think, exceptions are usually caught to do one of the following-

1. Continue current workflow with a default value.
2. Retry. Possibly with options to set the filter on Exception type, the number of retries and the delay between retries.
3. Retry in another way. Like read from file if network call fails.
4. A combination of above 3.
5. Logging or recording the exception.
6. Swallow the exception.

In my opinion, and "expression" makes sense for the first 4 types of handling. And instead of some variant of try expression proposed in the main post, it would be better to use some kind of cascading syntax like-

var result =
    NetworkCall()
        >|| retry { on: IOException, times: 3, delay: 50 }
        >|| AnotherNetworkCall()
        >|| retry  // implying retry once without delay on all exceptions
        >|| ReadFromFile()
        >|| default("A default value") { on: IOException };
// work with result

The operator >|| is an imaginary operator, which can be anything else, but ideally should imply cascading. Also, there is no explicit exception handling here. Just other means are provided to get the final result, in case of an exception. If a default value is not provided, and the last of the cascading expressions throws, the exception will be thrown. Or simply, the last part of the cascading expressions may still throw here.

For the point 5, logging/recording exceptions, I think it is a cross cutting concern. And some ways should be provided to log all exceptions in an application, at the caught-site, or at the crash-site. JS ecosystems provide something like this using events.

For the point 6, the swallowing of exceptions should be done with caution. This should only be done at the root of some workflow, to prevent crashing of the app/thread, which will prevent affecting other workflows.

This is my current opinion, which obviously can change in future.

Edit: Exception type filter for default.

Edit 2: I was trying to figure out what it would be translated to in current C#. I could not come up with anything without using goto-

string result;
int retries;

retries = 3;
while (true) {
    try {
        result = NetworkCall();
        goto success;
    } catch(IOException) {
        if (--retries == 0){
            goto step2;
        }
        else Thread.Sleep(50);
    } catch {
        goto step2;
    }
}

step2:
retries = 1;
while (true) {
    try {
        result = AnotherNetworkCall();
        goto success;
    } catch {
        if (--retries == 0) goto step3;
    }
}

step3:
try {
    result = ReadFromFile();
    goto success;
} catch(IOException) {
    result = "A default value";
    goto success;
}

success:
// work with result

[MV10]

The amount of error information being ignored by that approach is staggering.

[gulshan]

If you include the suggestion for point 5, no error information is just ignored, it is logged.

[Pxtl]

I've already chimed in on this, but imho too many approaches here are trying to reinvent the wheel.

C# already has a lambda syntax that includes both single-line expressions and multi-line expressions that have side-effects. While it may defeat the spirit of the "try expression", I see no reason why it shouldn't be allowed. It solves the "try-with-log" common case, albeit in an ugly way. This lambda syntax works fine, and any "try expression" should just use that for catch-expressions. Inferring default for expressions that return void might look pretty, but it's not idiomatic C#. For a catch expression to be valid, it should return the same type as the try, or it should throw.

(note, my syntax uses a single catch with each type separated by commas instead of multiple catch statements to avoid the ambiguous "which try is this a catch for" problem that could be caused by nested unbraced try and catch statements).

var responseCode = try(DoHttpRequest().ReponseCode) catch (
    NotFoundException => 404, //don't need ex variable, use immediate value.
    HttpException ex when (ex.Code < 500) => ex.Code, //just pass-through the response-code
    HttpException ex => { //for 500 and up HTTP errors, log the error before returning
         logger.Error(ex);
         return ex.Code;
    },
    SomeSpecialCaseException ex => throw MyWrappingExceptionClass(ex), //this is a special case where there's a higher-level error handler that needs to tackle it
    Exception ex => {  //treat all other errors as 500s.
        logger.Error(ex);
        return 500;
    }
);

[HaloFour]

C# already has a lambda syntax that includes both single-line expressions and multi-line expressions that have side-effects.

The syntax you're suggesting is more a variant of a match expression, which may use the lambda operator but does not behave like lambda functions. They would rely on "sequence expressions" to support multi-line arms, or some other syntax, but it's highly unlikely that return will be used to yield a value from within the arm.

Beyond that, this is a similar approach to F#, which has separate match and try expressions. It works well enough, but it also means that transforming both the successful result and the failed result requires nesting, which, IMO, feels unnecessary to me.

[z16]

I really like this idea the best, for the reasons mentioned - we don't need new syntax, we're all familiar and comfortable with switch expressions now, and I think this should mirror switch expressions as closely as possible, to avoid confusion and language pollution.

@HaloFour's comment about sequence expressions is valid and needs to be considered, but I think it's still worth supporting the idea, even without statement blocks.

[z16]

While I like @Pxtl's suggestion the most so far, I wanted to comment on two things that affect most suggestions.

First, I think that you could completely skip the try keyword (in this suggestion, as well as most of the prior ones, except the ones that want to introduce a completely new type with try <expression>). Something like this should work without a try:

var _ = SomeFunction().SomeIntProperty catch {
    FileNotFoundException => -2,
    InvalidOperationException => -3,
    CustomException ce when (ce.SomeIndicator is false) => -4,
    _ => throw, // The `throw` keyword should imo be available, just as it is in a regular `catch` clause
};

I think that this construct is uniquely identifiable and should not cause any parsing ambiguities. Feel free to point out something I'm missing. I also think that no legibility is lost when omitting the try keyword, but maybe that's just because I've been messing around with this idea in my head, and I'm curious to hear input on it. But it would flow better, and also match the switch expression style, of a single keyword after an expression.

I also think that this should be somewhat simple to implement, since any construct of this form

<statement>(<try-expression> catch {
    <caught-exception-1> => <result-expression-1>,
    <caught-exception-2> => <result-expression-2>,
    <caught-exception-3> => <result-expression-3>,
    ...
    _ => <default-result-expression>,
})

should be translatable to this

<inferred-type> __value;
try {
    __value = <try-expression>;
} catch (<caught-exception-1>) {
    __value = <result-expression-1>;
} catch (<caught-exception-2>) {
    __value = <result-expression-2>;
} catch (<caught-exception-3>) {
    __value = <result-expression-3>;
}
...
catch {
    __value = <default-result-expression>;
}
<statement>(__value)

Second, since multiple people have mused about how to use finally, I personally don't think it makes a lot of sense in such a construct, nor do I think it has to. I don't think this idea should abolish the entire try/catch mechanism, but just offer a convenient shortcut for handling a certain subset of exception scenarios. Similar to how switch expressions didn't make the switch statement obsolete, but just provided a convenient shortcut of handling a certain subset of value disambiguation scenarios.

More broadly, I saw some people here make the argument that this idea lacks merit because it can't handle scenario X or Y of the regular try/catch mechanism, but just like with the finally clause, I don't think a full feature match is the end goal here. Even a simple implementation like the one suggested above would allow us to condense code like this:

public int SomeValue {
    get {
        try {
            return SomeFunction().SomeProperty;
        } catch {
            return -1;
        }
    }
}

To this:

public int SomeValue => SomeFunction().SomeProperty catch { _ => -1 };

Or maybe even this, if we also allow a shorthand for catch-all exceptions:

public int SomeValue => SomeFunction().SomeProperty catch -1;

All without a loss of clarity. I think every current C# developer would be able to grok the above code with a cursory reading.

And finally, to the people arguing against this suggestion because they don't see the merit in it - brevity may not be a virtue in every situation, but if it preserves clarity and legibility, it has many advantages over longer code. Less room for bugs, faster to type, to read, less vertical space wasted, less scrolling, etc. There's a reason why expression-bodied everything has been getting so popular.

[tacosontitan]

Personally, I'm not a fan of a try expression. Most of the use cases given in this thread already have solutions through making better decisions when writing your code. A handful of pointers that would make this recommendation obsolete in most of the specified scenarios would be:

• Apply inversion and extraction techniques to reduce nesting.
• Avoid condensing code purely for the sake of fewer keystrokes.
• Avoid control flow through exceptions.
  • Validate input to prevent exceptions.
  • Use result types when an exception isn't needed.

---

🚫 Exceptions are meant to be exceptional

Unfortunately, many developers do not attempt to prevent exceptions but rather simply handle them. However, most exceptions can be prevented through validation; and those that cannot, should (context aside), terminate the current process early. A good example is attempting to read all text from a file:

string content = await ReadAllTextFromFile(filePath);

...
private bool TryValidateFilePath(string filePath)
{
    if (string.IsNullOrWhiteSpace(filePath))
    {
        // would throw an argument null exception
        _logger.LogError("Unable to load samples because the file path is empty.");
        return false;
    }

    var invalidCharacters = Path.GetInvalidPathChars();
    if (invalidCharacters.Any(filePath.Contains))
    {
        // helps prevent not supported exception, but doesn't ensure it won't happen
        _logger.LogError("Unable to load samples because the file path contains invalid characters.");
        return false;
    }

    var filePathAttributes = File.GetAttributes(filePath);
    if (filePathAttributes.HasFlag(FileAttributes.Directory))
    {
        // unauthorized access exception can be thrown for trying to read a directory instead of a file
        _logger.LogError("Unable to load samples because the file path is a directory, not a file.");
        return false;
    }

    return true;
}

private Task<string> ReadAllTextFromFile(string filePath)
{
    try
    {
        if (!TryValidateFilePath(filePath))
            return Task.FromResult<string>(null);

        string result = File.ReadAllText(filePath);
        return Task.FromResult(result);
    }
    catch (PathTooLongException)
    {
        _logger.LogError("Unable to read text from the specified file path because the path is too long.");
    }
    catch (NotSupportedException)
    {
        _logger.LogError(
            "Unable to read text from the specified file path because the format of the path it is not supported.");
    }
    catch (Exception e) when (e is DirectoryNotFoundException or FileNotFoundException)
    {
        _logger.LogError(
            "Unable to read text from the specified file path because the directory was not found.");
    }
    catch (Exception e) when (e is UnauthorizedAccessException or SecurityException)
    {
        _logger.LogError(
            "Unable to read text from the specified file path because the file is read-only or the current user does not have access.");
    }
    catch (Exception e)
    {
        _logger.LogError(
            "Unable to read text from the specified fil path due to an unexpected issue. {ExceptionMessage}",
            e.Message);
    }

    return Task.FromResult<string>(null);
}

✅ My recommendation for a catch expression

In my personal opinion, the code snippet above is verbose, and we could give syntactical sugar for situations like that. However, I would limit it to just a catch expression. This means that the content of the try or any accompanying finally block would be considered out-of-scope for the expression, just as they are today. In addition to this, the expression would be limited to a single action per exception type being evaluated:

try
{
    if (!TryValidateFilePath(filePath))
        return Task.FromResult<string>(null);
        
    string result = File.ReadAllText(filePath);
    return Task.FromResult(result);
} catch => {
    PathTooLongException => _logger.LogError("The specified file path is too long."),
    NotSupportedException => _logger.LogError("The specified file path is invalid."),
    DirectoryNotFoundException => _logger.LogError("The directory for the specified path was not found."),
    FileNotFoundException => _logger.LogError("The specified file was not found."),
    UnauthorizedAccessException => _logger.LogError("Access to the specified file was denied."),
    SecurityException => _logger.LogError("Access to the specified file was denied."),
    _ => _logger.LogError("An unexpected issue occurred. {ExceptionMessage}", e.Message)
};

return Task.FromResult<string>(null);

My only issue with the above snippet is that I don't like how } catch => { reads, in any format I placed it in.

[DavidArno]

@tacosontitan
This is similar to ideas I've been playing with, but your catch => { idea fills in a gap that I hadn't thought of.

I was very much focused on try/catch expressions. You make an interesting case that the try part isn't needed, so I'll acknowledge that but I'm minded to agree with @z16 that there are plenty of valid use-cases of try expressions. So I will put it to one side for now. My thoughts on how your example might be expressed using a try/catch expression:

var task = 
    try (TryValidateFilePath(filePath) ? Task.FromResult(File.ReadAllText(filePath)) : NullTask())
    catch (
        PathTooLongException => LogAndReturnNullTask("The specified file path is too long."),
        NotSupportedException => LogAndReturnNullTask("The specified file path is invalid."),
        DirectoryNotFoundException => LogAndReturnNullTask("The directory for the specified path was not found."),
        FileNotFoundException => LogAndReturnNullTask("The specified file was not found."),
        UnauthorizedAccessException => LogAndReturnNullTask("Access to the specified file was denied."),
        SecurityException => LogAndReturnNullTask("Access to the specified file was denied."),
        _ => LogAndReturnNullTask("An unexpected issue occurred. {ExceptionMessage}", e.Message));

Task<string> NullTask() => Task.FromResult<string>(null);
Task<string> LogAndReturnNullTask(string message)
{
    _logger.LogError(message);
    return NullTask();
}

Like you, my thoughts were that the catch part of the expression would re-use the switch expression's pattern matching syntax. But I went full hog and figured the full functionality could be re-used. The grammar would be:

expression
      : try_expression
      | etc
      ;

try_expression
      : try '(' expression ')' catch '(' (switch_expression_arm (',' switch_expression_arm)* ','?)? ')'
      ;

There's a caveat there that throw would need to be supported in those expression arms.

Your idea is an interesting addition to this though, allowing the mixing of a try statement and an expression-based catch:

try_statement
    : attribute_list* 'try' block catch_clause* finally_clause?
    ;

catch_clause
    : catch_statement
    | catch_expression
    ;

catch_statement
    : 'catch' catch_declaration? catch_filter_clause? block
    ;

catch_expression
    : '=>' '(' (switch_expression_arm (',' switch_expression_arm)* ','?)? ')'
    ;

You example neatly shows that there are cases where a try block is needed, but the current catch syntax is not capable of succinctly expressing what's needed. Your idea solves that nicely.

[z16]

hat argument is easily disproven by considering how many people argue for it. All it says, is that it's not needed for you

The LDT has made it quite clear that "lots of people like the idea" isn't a major deciding factor. The lengthy arguments over automatic interfaces comes to mind.

And I'm not debating that, I'm just saying that it speaks against the "this isn't needed" narrative. Of course, you could argue semantics over what "needed" means in this context, but I don't think this belongs here, so let's just replace it with "wanted" for the sake of argument, since nothing is technically "needed" in these discussions. But either way, that's neither here nor there, so I won't go into that further.

[DavidArno]

A handful of pointers that would make this recommendation obsolete in most of the specified scenarios would be:

Apply inversion and extraction techniques to reduce nesting.

I'm unclear how this would help remove the need to handle exceptions inside expressions. Do you have an example?

Avoid condensing code purely for the sake of fewer keystrokes.

This is an awkward one for you as your catch expression example does nothing other than "condense code purely for the sake of fewer keystrokes". But it is still a good point. I just don't see how it's relevant to needing to handle exceptions inside expressions.

Avoid control flow through exceptions.
Validate input to prevent exceptions.

I really don't see how either of these are related to exceptions inside expressions. Again do you have examples?

Use result types when an exception isn't needed.

I certainly agree with this one. But until we get unions in C#, this remains a clunky solution that's often best avoided, sadly.

[tacosontitan]

I really don't see an argument against this idea anywhere in your post.

@z16, I do argue against a try expression:

Most of the use cases given in this thread already have solutions through making better decisions when writing your code.

I don't claim that the feature isn't needed, but simply that I'm not a fan of it. In fact, I continue to point out that if we introduced such a feature, I would prefer that we limit it to a catch expression, keep the try and finally out-of-scope, and limit the expressions to non-mutative actions (such as logging).

My argument is that using exceptions for control flow is generally bad practice; because, well, to quote my original response:

...most exceptions can be prevented through validation; and those that cannot, should (context aside), terminate the current process early.

You go on to state that:

If you use a library that happens to throw an exception in some place that you'd like to catch and return a different value with, there's not much you can do externally.

However, you can, as I proved with my snippet around using File.ReadAllText; just create an encapsulation for interacting with the external process, notice my interaction with the process encapsulated the validation and the try-catch:

string content = await ReadAllTextFromFile(filePath);

Lastly, you also stated:

Finally, your suggestion does not even fit the proposal topic, since those aren't expressions.

That's my point, I'm not a fan of supporting expressions for the try or finally blocks, just the catch, and likely only in a limited context.

---

@DavidArno, I like how you gave an example to demonstrate mine with a try expression; I initially started down this path, but one thing, in particular, bothered me when attempting the same:

Task<string> LogAndReturnNullTask(string message)
{
    _logger.LogError(message);
    return NullTask();
}

This will cause analyzers to throw out a CA2254 for _logger.LogError(message):

The logging message template should not vary between calls.

Now, I'm not 100% against this, because ideally, you'd still employ good adherence when invoking LogAndReturnNullTask, so it becomes a false positive. However, with that, you also remove the enforcement at the individual invocation level which means that another developer with less experience around logging could come in and use interpolation or concatenation and truly violate CA2254 without knowing.

Additionally, I'm not a fan of the usage of a conditional operator because it is truly trying to condense code to make it work in an expression which shouldn't really be an expression:

try (TryValidateFilePath(filePath) ? Task.FromResult(File.ReadAllText(filePath)) : NullTask())

If we did have a try expression, I'd like to think that most, if not all senior developers would raise an eyebrow at using a conditional operator in it. That's a situation where, at a minimum, I would break it out to pre-validation:

if (!TryValidateFilePath(filePath))
    return Task.FromResult<string>(null);

string result = File.ReadAllText(filePath) catch {
    ...
};

return Task.FromResult(result);

_{I agree with @z16 that the try part isn't needed in that approach.}

Furthermore, you had a few concerns that I think I can address in a single pass:

• I'm unclear how this would help remove the need to handle exceptions inside expressions.
• I just don't see how it's relevant to needing to handle exceptions inside expressions.
• I really don't see how either of these are related to exceptions inside expressions.

Unless I misunderstand what you're asking (and it could be my lack of experience with discussing topics at this level), the number of scenarios where a try expression could truly be employed is incredibly minimal. This is simply due to the fact that the vast majority of situations where they will be used should actually be broken down for legibility, maintainability, diagnostic agility, and completeness; which the points I gave would certainly assist with (outside of an expression context).

As a result, I'm not a fan of the feature, but if we introduced something like this, I'd prefer it be limited to just the catch block.

[janis-veinbergs]

I see there are 2 things which people would enjoy about try/catch:

1. concise syntax - now braces here and there, doesn't allow lambdas thus cannot be written on a single line
2. expressions - allows inlining some stuff, enables more functional programming style - now excessive variable declarations outside of "try" scope to localise exceptions and use the result outside of try because the operations on result may have their own try and generic catch with different error message..

As I'm reading what's new in C#12 - the new features welcomes concise and terse syntax and often that is the "selling point".

I'd say concise syntax for catch encourages developers to write more meaningful error messages as you have less friction to do it.

I like to see that there is live discussion around this topic.

[MarkusRodler]

Isn't it possible to implement a JavaScript-like way of doing catch? For example you have an async function
await ToThrowOrNotToThrowTask();
Then you can catch the possible exceptions like that:
await ToThrowOrNotToThrowTask().catch(DoesNotWorkException e => {});
or that:
await ToThrowOrNotToThrowTask().catch<DoesNotWorkException>(e => {});

[Thaina]

It seem there is that kind of extension method in reactivex

But for task I think normal try/catch seem more sensible and more versatile than functional pattern

[CyrusNajmabadi]

@MarkusRodler that already exists today. You can just do .ContinueWith() on the task, specifying that you only want to run if it fails. You can trivially write an extension for that pattern as well if you wanted. That said, it would be highly non-idiomatic, as the point of async/await is to make it so that you use tasks in the normal control flow patterns you use for the rest of your code.

[MarkusRodler]

@CyrusNajmabadi Thanks for the reply. I tried it, but I can't get it to work. What am I doing wrong?

await WillFail().ContinueWith(Catch);
// await WillFail().ContinueWith(t => Console.WriteLine(t.Exception.Message.ToString()), TaskContinuationOptions.OnlyOnFaulted);

Task WillFail() => throw new Exception("Boom");

async Task Catch(Task task)
{
    System.Console.WriteLine("test");
    try
    {
        await task;
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message);
    }
}

[HaloFour]

You did not define WillFail as async, so it's throwing an exception instead of returning a failed task. If the method is async the compiler will emit code within the method to catch any exceptions and wrap them in a Task.