Allow singleline expressions in try-catch blocks

[weitzhandler]

Please allow omission of curly braces for single-statement try-catch blocks. I'm sure this small syntactic sugar has been proposed before, although I couldn't find it.

try
  client.Load();
catch (Exception e)
  logger.Log(e);
finally
  client.Dispose();

Just like:

if(!isValid)
  ShowError("error");

[yaakov-h]

@lachbaer Did you ever create the two separate proposals to follow on from #220?

[lachbaer]

@yaakov-h No, I thought that it wouldn't be worthwhile, because I have inspected some code and couldn't see how try expressions can be really useful. Most times a refactoring and more thorough exception handling seemed to be the better solution. Catch expression syntax catch (...) => return; however could be useful. I just haven't opened a topic for it.

And catch expressions clash with try expressions anyway, because they could be nested and then it will lead to catch ambiguity again, the reason why try-catch allow block statements only in the first place.

[weitzhandler]

@yaakov-h, I actually saw @lachbaer's proposal, but since it was closed and my proposal is a mere syntax sugar I thought about posting it separately having not found another one.

[yaakov-h]

A big issue we had in #220 was if you nest them, you have ambiguous behaviour.

For example:

try
    try
        DoTheThing();
    catch (ThingException e)
        HandleTheThingFailing();
  catch (Exception e)
      // What scope am I in now? This is ambiguous.
  finally
      // How about now?
    try
        // So this would be second-level for sure, right?
    catch (Exception e)
        // As would this
  finally
  // This would belong to the outer block if the first finally belongs to the inner one, otherwise the entire second try/catch/finally is not nested at all.

[weitzhandler]

1. The same problem is in if-else and else if.
2. It can be restricted to inline expressions, like:
   public string MyProperty => try { } catch { } //invalid

[lachbaer]

Of course rules that define the level of nesting could be defined, such as a finally always breaking the current level, giving control back to the previous try, catch or finally statement.

But because try-catch shall be a construct that clearly structures (mainly unexpected) error cases every further nesting only makes the flow more unclear.

If you only have one line that you want to try over, then you can just put the try-block in the same line, as long as it doesn't violate your style rules.

public void Method()
{
    int value;
    try { value = ErrorproneFunction(); }
    catch
    {
        // structured exception handling block
    }
}

This also emphasizes the explicit try.

Another scenario is a one-line block-less catch, because this seems to be more common. It would only reduce the occurance of 2 curly braces, but looks a bit better.

    try {
        statement1;
        statement2;
        statementN;
    }
    catch (IOException ex) => throw new MyIOException(ex);
    catch (NullReferenceException ex) => return;

Because those are expressions a nesting cannot occur (as long as try-expressions aren't ready).

[DavidArno]

The same problem is in if-else and else if.

Is that not a good reason to avoid adding those same problems to try catch?

[weitzhandler]

I agree but I don't see it as a problem. It's habit of the way we're predict our code. And since this habit already exists in the language and we're used to deal with it, I see no problem in having the same in other areas. Nested trys should be in braces just like nested ifs. Besides, there is option 2, of avoiding that by allowing only expressions.

[HaloFour]

@weitzhandler

The blocks are required because, unlike if/else, a try block can have any number of catch blocks. If you were to nest a single-line try under another single-line try and have more than two catch blocks there'd be no way for the compiler to determine which try statements that each of the catch blocks are associated with.

[weitzhandler]

So what?
Either a block or a single statement (or an empty one - e.g. { }) is required in any catch statement, just like it is now.

[HaloFour]

try try Foo(); catch (IOException) Bar(); catch (Exception) Baz(); catch Console.WriteLine("oops");

What's it do? There's two perfectly legal answers.

Update: Missing some necessary semicolons, fixed.

[YaakovDavis]

try
  client.Load();
catch (Exception e)
  logger.Log(e);

Just like:

 if(!isValid)
   ShowError("error");

The if statement ends with the ;, whereas the ; after the client.Load() call doesn't end the try statement as a whole.
This makes the cases somewhat distinct from a visual perspective.

[weitzhandler]

@HaloFour

try try Foo();

nesting try should only be allowed in blocks, has been discussed above

---

@YaakovDavis

The if statement ends with the ; whereas the ; ... doesn't end the try statement as a whole.

It ends the catch statement as a whole.
And the if doesn't completely end, else if statements can be following it.

[HaloFour]

@weitzhandler

nesting try should only be allowed in blocks, has been discussed above

So you'll need two flavors of the C# spec to deal with this possibility? Afterall, there could be any number of other nestable constructs under that first try. Expressing that in the spec would be obnoxious. Not to mention it would make refactoring a pain since the legality of the syntax would depend entirely on code external to that statement.

It's simply not worth it. If you want it all on one line feel free to wrap it in curly braces on that one line.

[lachbaer]

nesting try should only be allowed in blocks

In a statement's place every 'statement' is allowed, so try is allowed, too. Putting a restriction on this rule only on try, catch and finally would be quite an incision.

[shravan2x]

@HaloFour Maybe that's a good idea, maybe it isn't. But that decision should have been made before adding support for it with if-else statements. At this point, code (and the language as a whole) looks inconsistent when different rules have to be followed for different blocks of code.

In addition, the ambiguity itself only exists in edge cases. Like I mentioned before, the fact that some potential edge cases exist is not a good reason to discard the entire idea.

It's not worth it to save 4 characters.

Clarity of code is not measured solely by the number of characters.

[theunrepentantgeek]

But that decision should have been made before adding support for it with if-else statements.

The way that if-else statements works was carried forward from C (in fact, possibly from it's predecessor) so it's literally been around 50 years. Effectively this is grandfathered in to peoples thinking.

Clarity of code is not measured solely by the number of characters.

Yep. Totally agree with this.

Which is why I don't believe this idea has any merit - the only benefit it has is to reduce the number of characters typed, with an increased cognitive load for everyone reading the code.

Clarify of code is impaired by having ambiguous statement structures.

Regrettably it can't happen because it would be a major breaking change, but I'd prefer to go the route chosen by Go (and other languages) where the { braces } are required everywhere.

[shravan2x]

Effectively this is grandfathered in to peoples thinking.

I agree, which is why it feels unintuitive when people use the same logic to try-catch statements and realize it doesn't work.

the only benefit it has is to reduce the number of characters typed, with an increased cognitive load for everyone reading the code.

I don't agree that the only benefit is to reduce the number of characters typed. Having fewer characters is certainly a side-effect, but the main reason is that removing braces reduces the cognitive load for people reading the code.

I understand you disagree with this, and people may well have divided opinions on it. But there certainly are a significant portion of people on this side of that divide. Individual teams could make this choice for themselves by setting code style preferences.

Clarify of code is impaired by having ambiguous statement structures.

Not all forms of this syntax are ambiguous. There are many valid use-cases for this feature that work well.

It can potentially be ambiguous when used in certain ways (which is also the case with many other C# features), the responsibility is on the developer to make the right choice in each situation.

Regrettably it can't happen because it would be a major breaking change, but I'd prefer to go the route chosen by Go (and other languages) where the { braces } are required everywhere.

That's an interesting opinion, I don't entirely disagree with it.

[HaloFour]

@sachevl

but the main reason is that removing braces reduces the cognitive load for people reading the code.

Punctuation matters. Removing it increases the cognitive load because now the reader has to understand how the compiler is going to parse those statements and whether or not the whitespace used by the author actually matches those rules. Relying on trivial whitespace is how bugs get introduced. The braces serve as punctuation and forces disambiguation for the reader.

This was already clear 30 years ago, which is why C++ has never had a form of try which allowed for the omission of braces.

[CyrusNajmabadi]

But that decision should have been made before adding support for it with if-else statements.

If we had a time machine, perhaps someone could go back and work to make that happen 23 years ago. :)

looks inconsistent when different rules have to be followed for different blocks of code.

As someone who knows the C# grammar inside and out, i can tell you it is massively inconsistent. To the point where i would practically argue that consistency is a non-goal (or very minor goal). When we design new stuff we consider this a bit, but it's not what we're optimizing for. Furthermore, for stuff that has already shipped, we're not going to change it just for the sake of consistency. There has to be serious value delivered on top of that for it to happen. I'm just not seeing it here.

[shravan2x]

@HaloFour

Punctuation matters. Removing it increases the cognitive load because now the reader has to understand how the compiler is going to parse those statements and whether or not the whitespace used by the author actually matches those rules.

Removing braces increases the cognitive load because the reader now has to create a new mental stack frame for each new block in the try-catch statement. If there's just a single statement, it's simpler to read because it doesn't create a new frame. The feature is sufficiently disambiguous, and clearer for the reader.

But like I said before, people may well have divided opinions on this. Your opinion need not necessarily be held by every user of C#. Clarity is a subjective measure and code isn't clearer to everyone simply because it's clearer for you. There are a significant number of users who find it clearer without the braces. Individual teams could make this choice for themselves by setting code style preferences.

@CyrusNajmabadi

If we had a time machine, perhaps someone could go back and work to make that happen 23 years ago. :)

If only! :)

As someone who knows the C# grammar inside and out, i can tell you it is massively inconsistent. To the point where i would practically argue that consistency is a non-goal (or very minor goal). When we design new stuff we consider this a bit, but it's not what we're optimizing for.

You may be right, but my opinion is that working to smooth out kinks is always a good direction to aim for, even if it takes a lower priority. I certainly don't expect that this feature should outweigh others that the community finds better value in.

Furthermore, for stuff that has already shipped, we're not going to change it just for the sake of consistency. There has to be serious value delivered on top of that for it to happen. I'm just not seeing it here.

That's a fair point - this feature is functionally just syntactic sugar. But consistency is not the only reason, clarity is another important one. A number of new features (like Expression Bodied Members from C# 6) fall in similar categories, but were still added.

[CyrusNajmabadi]

A number of new features (like Expression Bodied Members from C# 6) fall in similar categories, but were still added.

This falls into the "There has to be serious value delivered" bucket. There's likely a 1000x (or more) benefit to expression bodied members versus braceless-try-statements.

[shravan2x]

This falls into the "There has to be serious value delivered" bucket. There's likely a 1000x (or more) benefit to expression bodied members versus braceless-try-statements.

Why do you hold this opinion? Doesn't it also just avoid two extra braces and a return statement i.e. creating a block of code?

[CyrusNajmabadi]

Why do you hold this opinion?

Because the amount of code that uses properties (esp. very trivial ones) is massively more than the amount of code that needs to use trivial try/catches.

[shravan2x]

@CyrusNajmabadi Fair point. Another example of a feature that arguably delivers less value than this one is Enhancement of interpolated verbatim strings.

[333fred]

@CyrusNajmabadi Fair point. Another example of a feature that arguably delivers less value than this one is Enhancement of interpolated verbatim strings.

And that issue has significantly less cost and doesn't result in complicated and hard-to-reason-about ambiguity resolution rules.

[Thaina]

@shravan2x

I agree that it's confusing, but it has already been added.

Not for try/catch it hasn't. And, as I've repeated several times, for good reason. It's impossible for the compiler to unambiguously parse it. For that reason alone it can't be added because there's nothing that the compiler can do.

The following may be considered bad practice, but at least it can only have exactly one meaning:

if condition
    if condition2
        statement1;
    else
        statement2;

But the following can mean literally three semantically different but perfectly legal things:

try
    try DoSomething()
    catch (FooException e) HandleFoo(e);
    catch (BarException e) HandleBar(e);
    catch (BazException e) HandleBaz(e);
finally CleanUp();

There's simply no correct way for the C# compiler to parse that. The only catch clause that can be unambiguously associated with a try clause is the first one. All of the rest could belong to either try clause.

And that aside, the fact that if/else does support embedded statements that aren't blocks is not reason to repeat that mistake elsewhere.

What if we strictly define that the try-catch block muct end with ; ?

try
    try DoSomething()
    catch (FooException e) HandleFoo(e)
    catch (BarException e) HandleBar(e)
    catch (BazException e) HandleBaz(e); // inner
finally CleanUp(); // outer

// comparison

try
    try DoSomething()
    catch (FooException e) HandleFoo(e)
    catch (BarException e) HandleBar(e); // inner
catch (BazException e) HandleBaz(e)
finally CleanUp(); // outer

// one line

try
    try DoSomething() catch (FooException e) HandleFoo(e); // inner
catch (BarException e) HandleBar(e)
catch (BazException e) HandleBaz(e)
finally CleanUp(); // outer

Or we could also use , like a switch expression to separate between catch expression?

[cnapolit]

Is there any reason why requiring curly braces for nested try-catch statements that are not already contained in a code block wouldn't solve the ambiguity?

try
{
    try
       action();
   catch (Exception e)
       Cleanup(e);
}
catch (Exception e)
    Cleanup(e);
try
{
    foreach(var variable in variables)
        try
            action(variable);
        catch (Exception e)
           Cleanup(e);
}
catch (Exception e)
    Cleanup(e);

Otherwise, any nested try inside of a nested block would not be ambiguous by the logic 'this try is linked to all immediate catches within the given code block':

// Admittedly, 'try foreach' kind of reads like:
// "upon each iteration, try the given code block"
// Rather than:
// "try this foreach statement"
// which is not good for new C# users
try foreach(var variable in variables)
{
    try
        action(variable);
    catch (Exception e)
       Cleanup(e);
}
catch (Exception e)
    Cleanup(e);

I would wager the biggest con just from a syntax point of view is that users unfamiliar with this form of try-catch could be confused both what it is doing and why their compiler/IDE is forcing them to use curly braces when they first attempt to use it.

If this took little to no effort to implement and analyze, I would be in favor of it.

However, given:

• Just about any change to a language is non-trivial
• Analysis is more complex than just 'find the previous if in the current block'
• The subjective syntax benefit
• The controversy around the subject

it's unsurprisingly not a good idea to implement try statements (and thus catch statements, for consistency) without curly braces.

[notato8dx]

The syntax may be subjective, but the proposal is not. It's backwards compatible, so each developer would either benefit from the addition, or experience no change at all. This is an objective improvement.

I agree that countless examples of unreadable code have been given, which would be enabled by this proposal. This is negligible when you consider that many developers would use the proposal to enhance the readability of their code. Analyzers exist to solve this problem.

The precedent of nested if statements is used an example to argue that this proposal could create ambiguity with catch blocks. However, this problem has been clearly solved in the specification, which states

An else part is associated with the lexically nearest preceding if that is allowed by the syntax.

Applying the same principle to try-catch statements leads to the conclusion: any catch block is associated the nearest preceding try block that hasn't been concluded by a finally block. There was never any ambiguity to begin with.

[CyrusNajmabadi]

@notato8dx see #4676 (comment)

[CyrusNajmabadi]

This is an objective improvement.

It is not, as brevity is not objectively better.

[notato8dx]

@CyrusNajmabadi

This is an objective improvement.

It is not, as brevity is not objectively better.

My stance is not that brevity is objectively better. It's that giving developers the option is objectively good.

@notato8dx see #4676 (comment)

It's not just about saving a few characters from removing the brackets. I actually agree that the one-line examples you offered are less readable. The benefit would come from reducing the complexity of nesting multiple block statements. Consider these common examples:

if (condition) {
    ...
} else if (condition) {
    ...
} else {
    ...
}

using (disposable)
using (disposable) {
    ...
}

In the opinions of many developers (maybe not to the same extent with the using statement example), these are more readable than the alternative of strictly using blocks:

if (condition) {
    ....
} else {
    if (condition) {
        ...
    } else {
        ...
    }
}

using (disposable) {
    using (disposable) {
        ...
    }
}

With try, catch, and finally blocks, this would enable things like:

try {
    ...
} catch (Exception) {
    ...
} finally try {
    ...
} catch (Exception) {
    ...
}

try {
    ...
} finally if (condition) {
    ...
}

Also, this has the side bonus that you can have an empty catch statement without brackets.

try {
    ...
} catch (Exception);

[CyrusNajmabadi]

It's that giving developers the option is objectively good.

That is not our stance. As I mentioned in my linked post, there are a huge number of places we could make tokens optional. Even though I'm an those cases it would be developer choice, we still would view it as actively bad for the language and ecosystem to have all the confusing forms.

We are judicious where we allow flexibility.

[CyrusNajmabadi]

With try, catch, and finally blocks, this would enable things like:

Tbh, all those cases make me less in support of this proposal.

[Thaina]

I think single line try better be considered as a subset of try expression #2734

Suppport try expression that can set variable or return value would be a lot more useful