shorter try/catch statements

[JaggerJo]

Proposal: Add try/catch statement without curly braces

This syntax is already common for single line if/else stetements, foreach loops, for loops and using blocks. It would be convenient if the same pattern would be applied to the try/catch statement, because it would shorten a lot of code;

Single line if statement:

if (condition)
    return true;
else
    return false;

Single line try/catch statement:

try
    await SendDataAsync(data);
catch (Exception e)
    ShowDialogAsync(...);
finally
    ...

VS.
Single line try/catch statement:

try
{
    await SendDataAsync(data);
}
catch (Exception e)
{
    ShowDialogAsync(...);
}
finally
{
    ....
}

[DavidArno]

Duplicate of #616.

The reason this idea gets downvoted is because it wouldn't work with nested try/catches. Nested if/else's without braces aren't ambiguous. try/catches would be.

[MkazemAkhgary]

@DavidArno by the way nested if else statement for me is ambiguous. its pretty much opinion based.

if(cond)
    if(cond2) DoSomething();
else DoSomethingElse(); // because of wrong intent you may expect its for "!cond" branch.

It happened to me quite few times, so I stopped ever removing braces for nested if statements.

[GeirGrusom]

@DavidArno

Nested if/else's without braces aren't ambiguous.

They're by definition unambiguous, but the syntax itself is absolutely ambiguous.

if(foo)
    bar();
else if(foo2)
    bar();
else
    bar();

This expression can be parsed in two separate ways:

(if (else-if (else)))

or

(if (else (if (else))))

The parser will just select the first option given the chance.

edit: this is the reason why some languages use elif (C preprocessor) or elseif (BASIC) instead of else if.

[HaloFour]

@MkazemAkhgary

Ambiguous to you, but not ambiguous to the compiler. The compiler only has one rule for how to deal with that. An else clause belongs to the last immediate if statement. But that only works because there can only be at most one else statement. There can be any number of catch clauses.

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

There are three perfectly legal interpretations of that code. To quote Bjarne Stroustrup on the subject:

There seems to be no reason to allow these ambiguities even if there is a trivial and systematic way for a parser to chose one interpretation over another. Consequently, a { is required after a try and a matching } before the first of the associated sequence of catch clauses.

[MkazemAkhgary]

I see, removing braces for catch only wouldn't be ambiguous though.

[DavidArno]

@GeirGrusom,

They're by definition unambiguous, but the syntax itself is absolutely ambiguous.

Your point is well made there. That'll teach me to be lazy. 😀

@HaloFour

Ambiguous to you, but not ambiguous to the compiler

Interestingly (for me, at least), back in the day when I was using the unix tools, lex and yacc, to create "compiler" front ends, it was the case that the C language grammar could not be expressed with the yacc rules without an ambiguity warning on if .. else. Modern parsers though are more sophisticated and can handle that ambiguity. As @GeirGrusom says, the syntax is ambiguous, but it doesn't matter when it comes to resolving it, unlike with try/catch as you explain.

[HaloFour]

@DavidArno

True, the syntax is ambiguous, but the decision was made to treat it unambiguously following some pretty simple rules, for better or worse. The same kind of rules could be applied to try but they would be more complex and less intuitive which would only compound the known problems that developers still sometimes face when they use if/else without blocks and indent improperly.

[JaggerJo]

Would'nt it be a solution to require a finally block on nested single line try/catch blocks ? the finally block could act a bit like a break;

try
    try
        ...
    catch (SomeException e)
        ...
    finally;
catch
    try
        ...
    catch
        try
            ...
        catch (SomeException e)
            ...
        catch (Exception e)
            ...
        finally;
    finally;
catch (Exception e)
    ...
finally;

[HaloFour]

@JaggerJo

Why is that better than requiring braces? In most cases it would end up being more verbose than just requiring the blocks.

[JaggerJo]

@HaloFour

Not nested -> finally not required

try
    ...
catch
    ...

Nested -> Requires Finally

try
    ...
catch
    ...
catch
    try
        ...
    catch
        ...
    catch
        ...
    finally;
finally;

It's a bit like ambiguous references. When there could be confusion you have to be verbose/explicit otherwise not.

[HaloFour]

I still don't think that improves the language in any way. It's not less verbose and now you have to know two sets of syntax and when to use which. The grammar also becomes dependent on the context in which it's used, making try try semantically different from try. No other part of the C# language behaves like this.

[JaggerJo]

@HaloFour I get your Point.

[bondsbw]

Single line if statement:

if (condition)
    return true;
else
    return false;

I wish this weren't legal syntax. Someone will inevitably write more lines of indented code (or copy/paste them) under else and visually identify it as only executing when else executes.

This is precisely the reason behind the infamous Apple "goto fail" SSL bug.

I would be ok with single-line unbraced statements such as

if (condition) return true;
else return false;

Unfortunately, allowing that also allows the unbraced multi-line version, given that it's a design principle of C# to be whitespace agnostic.

[jnm2]

Someone will inevitably write more lines of indented code (or copy/paste them) under else and visually identify it as only executing when else executes.

Oddly enough, I have never seen this happen and I drop the braces all the time.

[bondsbw]

@jnm2

never seen this happen

That's the point. It's fairly invisible and not easy to notice. "Goto fail" was in the wild for several years on both iOS and OS X before being discovered and fixed.

It can also be easily overlooked during merge.

[jnm2]

@bondsbw I mean out of all the bugs I've diagnosed, none have been due to accidental misleading indentation/missing braces. Maybe it's a side effect of the auto formatting IDEs do out of the box these days.

[bondsbw]

@jnm2 Good point.

[Thaina]

As for me I never drop brace when nested. But in the real world we almost not nest try/catch block, even more so for one line nested try/catch block. But one line try/catch is very common

So I don't see any reason to go against this idea because ambiguity

[Joe4evr]

[johnathaningle]

It is personal preference. I personally find that the braces make for more verbose, harder to read syntax. It would be nice if this feature was optional to satisfy the dedicated "braces people" and people who are more "tabby." Why do we have brace-less if statements but require them for try/catch? It doesn't make much sense to me.

[gulshan]

I tried to explore how try expressions can look like in #2734 . It mostly keeps braces for catch part but eliminates it from try part.