[Proposal] Try Expression Syntax (try var)

[tugberkinci]

Summary

Currently, the C# language requires the use of a full try-catch block when handling potential exceptions. While this structure is useful for complex operations, it can become overly verbose when handling simple cases. I propose a new syntax that allows a more concise and readable way to handle exceptions when working with single expressions.

Proposal

Introduce a new syntax that mimics the behavior of the using var statement but applies to error handling. The proposed syntax would look like this:

try var result = GetData();
catch (Exception ex) => Console.WriteLine(ex.Message);

Motivation

The current syntax for handling exceptions often results in unnecessary verbosity, especially when the intention is to simply log the error or handle a single expression. A more concise syntax would:

1. Improve readability by reducing boilerplate.
2. Be especially useful in scenarios where only a simple action is needed on error.
3. Make the language more expressive and modern, aligning with other recent syntax improvements.

How It Would Work

• The try var syntax would be syntactic sugar for a try-catch block.
• It would be limited to single-line expressions, similar to the using var pattern.
• The result would automatically be scoped to the try block.
• If the operation fails, the catch statement would handle the exception directly.

Example Use Cases

1. Logging a simple error:

try var data = GetData();
catch (Exception ex) => Console.WriteLine(ex.Message);

2. Default assignment if failed:

try var value = GetConfigValue();
catch (Exception) => value = "default";

Alternatives Considered

The current way to handle similar cases involves writing the full try-catch block:

try {
     var result = GetData();
 }
 catch (Exception ex)
 {
     Console.WriteLine(ex.Message);
 }

While functional, this approach is unnecessarily verbose for simple scenarios. The proposed syntax would streamline common patterns.

Drawbacks

• The proposed syntax may seem less intuitive for more complex scenarios.
• Limited to single-line error handling, which might not fit every use case.

Conclusion

Adding a try var syntax would make C# more concise and user-friendly for developers who need to handle simple error scenarios without the verbosity of a full block. I believe this change could improve code clarity and make the language more elegant.

[HaloFour]

See: #4676, #1015

try var data = GetData();
catch (Exception ex) => Console.WriteLine(ex.Message);

doesn't seem much shorter than

try { var result = GetData(); }
catch (Exception ex) { Console.WriteLine(ex.Message); }

[spydacarnage]

It doesn't seem much shorter, but there is a significant implication to the change, especially in version 2 of the original proposal.

The implication being that data would continue to exist after the try/catch, which it currently doesn't do.

[tugberkinci]

You make a great point, and I actually see the variable being accessible outside the try-catch as a benefit rather than a drawback.
One of the primary advantages of the proposed try var syntax is that it allows the variable to be declared and used outside the try-catch structure while still being initialized within the block. This is especially useful in scenarios where you want to update the variable in case of an error and continue using it afterwards.
For instance, consider the following use case with the traditional syntax:

int a = 0;
try
{
    a = Calculate();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    a = -1;
}
Console.WriteLine(a); // Continue using the variable

With the proposed syntax, this would be much more concise:

try var a = Calculate();
catch (Exception ex) => a = -1;
Console.WriteLine(a); // Continue using the variable

This way, the variable can be initialized and updated within the try-catch block while being accessible outside for further operations. This pattern is quite common when handling error-prone calculations or operations that might fail.
Thank you for pointing out this important consideration, as it highlights a useful aspect of the proposal that makes error handling both cleaner and more practical

[tugberkinci]

I understand that the difference in line count might not be significant, but the main goal of this proposal is not just to reduce lines but to increase readability and code elegance.
The proposed syntax leverages modern C# conventions, like expression-bodied members, which make the code more concise and expressive.
This approach aligns with the direction of recent language updates that favor shorter, more readable syntax where possible.
A smilar change was introduced with the using var syntax, which allows for cleaner and more concise resource management. Instead of writing:

using (var stream = new StreamReader("file.txt"))
{
    var content = stream.ReadToEnd();
}

We now prefer the shorter and cleaner:

using var stream = new StreamReader("file.txt");
var content = stream.ReadToEnd();

This shorter form not only saves lines but also makes the code more readable. Similarly, the try var syntax aims to make exception handling more compact and readable, especially for single-line operations.
Especially when the purpose is to log an error or set a default value, the proposed syntax significantly reduces verbosity compared to the traditional block structure.
Additionally, the try var syntax would feel more natural to developers who have embraced the modern, expression-oriented approach in C#.

[HaloFour]

Your proposal isn't shorter than existing syntax. It can just as easily span two lines, or a single line, if desired. The language has no opinion regarding the whitespace you put around these constructs. Cleanliness isn't measured by the number of curly braces you can remove.

[theunrepentantgeek]

With using, it was extremely common for the scope to extend to the end of the current block, so the new syntax is just making that implicit. The improvement was made to address a very common case.

This has been the story for the majority of these syntactic sugar changes in recent versions of C# - making common cases better.

By contrast, a try..catch that only wraps a single statement is (at least in any of the code I've worked with or read) exceedingly rare.

[theunrepentantgeek]

Make the language more expressive and modern, aligning with other recent syntax improvements.

Syntactic sugar by definition doesn't make the language more expressive.

And I disagree with the assertion that this syntax is modern, or that is aligns with other recent syntax changes. This is nothing more than a more limited form of the previously requested "single line try-catch" (as linked by @HaloFour, above) but with more limitations and baggage.

[jaredpar]

I'm generally in favor of trying to find ways to make this syntax more succinct. I think the key though is getting it to the point that it can be expressed as an expression instead of a statement. For example:

var value = try GetConfigValue() catch default;

Essentially adding a try <expr> catch <expr> expression form that expands out to the existing try / catch statement. That will both shorten the syntax but also expand the usability of exception handling into expressions.

[HaloFour]

I think there's value in considering an expression form of try, but I do hope that the language team balances that against a syntactic form that would encourage developers to swallow exceptions indiscriminately, which is almost always the Wrong Thing™️ to do.

I personally prefer Java's proposed take on this:

var result = switch (Integer.parseInt(s)) {
    case int i -> i,
    case throws NumberFormatException ex -> {
        log.error("Oops", ex);
        yield 0;
    }
};

[tugberkinci]

I really like the idea of Java’s proposal using switch with throws, and I think C# already offers a similarly expressive pattern through switch expressions. For example:

var result = s switch
{
    string str when int.TryParse(str, out var value) => value,
    _ => LogAndReturnDefault(s)
};

int LogAndReturnDefault(string original)
{
    Console.WriteLine($"Failed to parse: {original}");
    return 0;
}

While this doesn't handle exceptions directly in the switch, it encourages explicit error handling paths using expressions, which aligns with the spirit of Java’s proposal.
Similarly, the proposed syntax is not about ignoring exceptions, but rather about giving developers a more concise tool when they are already handling the exception meaningfully — logging it, defaulting a value, or performing a fallback.

[hez2010]

It can be covered by active patterns:

var result = s switch
{
    int.TryParse(out var value) => value,
    _ => LogAndReturnDefault(s)
};

int LogAndReturnDefault(string original)
{
    Console.WriteLine($"Failed to parse: {original}");
    return 0;
}

[HaloFour]

Active patterns can't handle exceptions thrown by the expression itself.

And yes, I am aware that int.TryParse exists. The fact that you can rewrite that one specific use case to use a completely different method that does not throw is not relevant to the demonstration of the syntax.

[martin-steinhoefer]

I'm generally in favor of trying to find ways to make this syntax more succinct. I think the key though is getting it to the point that it can be expressed as an expression instead of a statement. For example:

var value = try GetConfigValue() catch default;

Essentially adding a try <expr> catch <expr> expression form that expands out to the existing try / catch statement. That will both shorten the syntax but also expand the usability of exception handling into expressions.

I could not disagree more: Exception handling is something that should be taken seriously.

What happens with your program, if the exception thrown there is an OoM? Such an exception can happen at any time (you don't know, what GetConfigValue() really does - do you?). Just returning the default (or evaluating any other possible costly expression) might not be the best action in that case...
I personally would like the exception to blow up the app-domain (what can you really do, if allocating a box for an int fails?).

If one really wants a function that ignores exceptions, please go ahead and write it for yourself (and be held responsible for doing so):

public _ TryGetConfigValue()
{
    try 
    { 
        return GetConfigValue(); 
    } 
    catch // catch them all and live with the analyzer warning (which is there for a reason)
    { 
        return default; 
    } 
}

var value = TryGetConfigValue(); // et voilà there is your concise, succinct syntax

I think, the responsibility to ignore exceptions should not be shifted towards the language, but remain at the programmer.

[GabeSchaffer]

The nice thing about the Java proposal is that it naturally allows handling of multiple exception types. I kind of like what a C# equivalent of the Java example might be:

var result = int.Parse(s) switch {
    var i => i,
    catch FormatException ex => LogAndReturn(ex),
    _ => 0,
};

Though that's a bit ambiguous, because a reader might think that if int.Parse() throws OverflowException, the result is 0 instead of the exception escaping the statement. Perhaps it should be required that any catch must appear after a _ to make it clear that the exception arms are evaluated separately.