[Good Proposal]™ Expression-bodied try catch like get set

[dangi12012]

This would make Try Catch MUCH less verbose to what it is now:
Since C# 6.0 we can have simple Lambda properties:

string name;
public string Name
{
      get => name;
      set => name = value;
}
public string FullName => $"{FirstName} {LastName}";

It would be VERY cool to have this kind of lambda available for Try Catch:

try => WebClient.DownloadFile(path);
catch(WebException ex) => Log(ex);

EDIT: This example shows the advantage much cleaner. Try the following code with current state of C#:

try
{
      try => Foo();
      catch(BarException) => return null;
}
catch(Exception e) => Log(e.Message);
finally => Free(UnmanagedResource);

If you compare how much boilerplate code was necessary for get;set before C#6.0 you can clearly see how how similar Try Catch is to that. This way code gets less verbose and more readable 👍
What do you think about Expression-bodied try catch?

[theunrepentantgeek]

The semicolon (;) usually found at the end of a statement - your suggested syntax has it showing up in the middle of the try/catch which is not only very jarring but inconsistent with the rest of the language.

Single line syntax for get/set is attractive because the implementations are very commonly single line.

In my experience, try/catch blocks are quite the opposite. The try part of the statement is typically several lines of code, and if I ever see a single line catch block during a code review it's almost always a sign that something important has been omitted.

I'm pretty sure this has been suggested before, but couldn't find it with a brief search.

[Aside: I believe the community convention is to use the tag [Proposal] only. If you didn't think it was a good idea, you wouldn't be posting it. Whether the rest of the community thinks it is a good idea is up to them.]

[HaloFour]

@dangi12012

With braces with try/catch are required to establish to which try each catch belongs as any given try can have 0...many catch clauses. The compiler would not be able to disambiguate what the following means:

try => DoFizz();
try => DoBuzz();
catch (FooException ex) => HandleFooException(ex);
catch (BarException ex) => HandleBarException(ex);
catch (BazException ex) => HandleBazException(ex);

[MgSam]

You could easily make a utility method to do this for you without needing to modify the language.

[ufcpp]

Good proposal but very similar to

• single line try-catch: Allow singleline expressions in try-catch blocks #616 shorter try/catch statements #1015
• try-catch expression: try/catch expression #786 try catch expressions. #1068
• => ewerywhere: Allow => everywhere #1210

[Joe4evr]

[Good Proposal]

No it isn't. And please search before opening an issue, we've already seen #220, #616, #786, #1068 asking for exactly the same thing, and all of them are shut down for the exact same reason.

[gulshan]

I also proposed a try-catch expression at #980

[dangi12012]

Well you see that people independent of each other come up with the same idea shows that there is merit in the idea.
Of course simple Lambda Try Catch cannot be nested but would make it easier for most cases. Also since it would be a new feature it could be mixed with old try/catch:

try
{
      try => Foo();
      catch(BarException) => return null;
}
catch(Exception e) => Log(e.Message);

Now try that with current state of C# and see how good it looks ;)

[theunrepentantgeek]

people independent of each other come up with the same idea shows that there is merit in the idea.

There are a lot of counter-examples that prove this is false. Take your pick.

try
{
    try
    {
        Foo();
    }
    catch(BarException)
    {
        return null;
    }
}
catch(Exception e)
{
    Log(e.Message);
}

There you go, easy. This isn't hard to read.

Of course, there is value in being brief and concise - but that has to be weighed against other constraints as well. Having ideas like this one suggested over and over again doesn't make it them good ideas, just obvious ones.

[iam3yal]

Well you see that people independent of each other come up with the same idea shows that there is merit in the idea.

Here is the thing how many times do you have to deal with exceptions yourself as opposed to write actual logic?

The only reason you get to the same idea is because it's one of the few blocks in the language that doesn't have an expression form and so asking for it is almost inevitable but it doesn't mean something should be done about it.

[Unknown6656]

How about the following solution (It even works since C# 3.0 !!):

public static void @try(this Action body, Action<Exception> single_catch)
{
    try
    {
        body();
    }
    catch (Exception e)
    {
        single_catch(e);
    }
}

public static void @try(this Action body, params (Predicate<Exception> condition, Action<Exception> body)[] multiple_catch_bodies)
{
    try
    {
        body();
    }
    catch (Exception e)
    {
        foreach (var @catch in multiple_catch_bodies)
            if (@catch.condition(e))
            {
                @catch.body(e);

                break;
            }
    }
}

This could be used as such:

@try(
    () => Console.WriteLine(1 / 0),
    e => Console.WriteLine("Uh-oh! Some Error occured: " + e.Message)
);

// catch with conditions (like 'when'-clauses)!
@try(
    () => Console.WriteLine(File.ReadAllText("/invalid/file_path")),
    new (Predicate<Exception>, Action<Exception>)[]
    {
        (e => e is ArgumentNullException, _ => Console.WriteLine("Argument was null!")),
        (e => e is FileNotFoundException, _ => Console.WriteLine("File not found!")),
        (e => e is IOException io_ex && io_ex.HResult == 42, e => Console.WriteLine("Something nasty: " + e)),
        (_ => true, e => Console.WriteLine("Some other exception: " + e))
    }
);

[stakx]

@Unknown6656 - Sorry, but in my opinion, your @try helper method is rather horrific. 🙈

1. The resulting code looks bad.
2. And it is hard to read.
3. And it is going to perform worse than plain try..catch blocks. Your @try helper method involves a heap of avoidable allocations (a delegate instantiation for body, an array allocation for the multiple_catch_bodies parameters, and a delegate instantiation per item in multiple_catch_bodies). You're going to pay this allocation cost no matter what, even when no exception gets thrown.