Proposal: Allow try to modify using/switch statements

[heaton84]

This is a simple reduction in braces request. Often times, I find that spinning up an unmanaged resource requires a coinciding try/catch handler. For example:

try
{
    using (DatabaseInterface db = new DatabaseInterface())
    {
        db.Connect();
        db.DoSomeStuff();
    }
}
catch (Exception ex)
{
    Log("Database failed to DoSomeStuff: {0}{1}", ex.Exception, ex.StackTrace);
}

Can be shortened a few lines as follows:

try using (DatabaseInterface db = new DatabaseInterface())
{
        db.Connect();
        db.DoSomeStuff();
}
catch (Exception ex)
{
    Log("Database failed to DoSomeStuff: {0}{1}", ex.Exception, ex.StackTrace);
}

This can also be extended to a switch statement:

try switch (workType)
{
    case 0:
        workerClass.Zig();
        break;

    case 1:
        workerClass.Zag();
        break;
        
    default:
        throw new NotImplementedException(someVariable.ToString());
}
catch
{

}

I feel like this helps avoid needless syntax, while still clearly describing what is happening.

I don't see any additional complexities being introduced. Offhand, I can't think of any other keywords that require braces that this could be extended to beyond using and switch.

[TheUnlocked]

A more general solution would be to just allow try/catch to be used on a single line and not require braces, like with if/else:

if (pred)
    doSomething();
else
    doSomethingElse();

[yaakov-h]

@TheUnlocked allowing that is basically impossible due to nesting and multiple catches, and has been discussed extensively already in other issues.

[YairHalberstadt]

@yaakov-h

Why is that any different to

if (a)
if (b)
   M1();
else
    M2();

Where its ambiguous which if the else is attached to.

[yaakov-h]

@YairHalberstadt That reads ambiguously, but is actually well-defined. The else gets attached to the inner-most if.

On the other hand, how would you well-define this case?:

try
try
  M();
catch (IOException e) { }
catch (SystemException e) { }
finally { }

[YairHalberstadt]

@yaakov-h
Same. Arbitrarily define that everything gets attached to the innermost try.

[HaloFour]

@YairHalberstadt

It can't, every try needs a corresponding catch or finally, which means that you'd be assigning some number of those clauses to the nested try statements that are not innermost. Even if the behavior of the compiler could be well defined it would not be intuitive, it's simply not worth it.

Bjarne Stroustroup explicitly called this out in 16.8 Appendix D of Exception Handling for C++:

Allowing exception handlers to be attached to blocks only and not to simple statements simplifies syntax analysis (both for humans and computers) where several exceptions are caught and where nested exception handlers are considered (see Appendix E). For example, assuming that we allowed handlers to be attached to any statement we could write:

try try f(); catch (x) { ... } catch (y) { ... } catch (z) { ... }

The could be interpreted be in at least three ways:

try { try f(); catch (x) { ... } } catch (y) { ... } catch (z) { ... }
try { try f(); catch (x) { ... } catch (y) { ... } } catch (z) { ... }
try { try f(); catch (x) { ... } catch (y) { ... } catch (z) { ... } }

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.

[YairHalberstadt]

@HaloFour
I would simply make that an error.

[HaloFour]

@YairHalberstadt

I would simply make that an error.

Make what an error? The nesting of try statements without blocks?

[YairHalberstadt]

@HaloFour
Yes

[YairHalberstadt]

Though that would make it tricky to in the future add catches to using statements, since it would cause the following code to become an error:

try 
    using(...) 
        M();
catch {}

[HaloFour]

@YairHalberstadt

Maybe, I'd be curious to what you'd have to do to the spec to make having try try illegal but try anything else legal.

And frankly the savings here is minimal. You save two characters and an optional level of nesting. The IDE writes most of that for you.

You can already do using (...) try { ... } catch { ... }.

[yaakov-h]

try
    using (foo)
        try
            catch (Exception ex) { }
catch (Exception ex) // oops!

[YairHalberstadt]

@yaakov-h

That's a good point. I retract.

[heaton84]

I feel like the discussion got a little off the rails here. Trying to get back on point:

@HaloFour

Your using (...) try { ... } catch { ... } example has one flaw... the instantiation of the object in the using block can throw an exception, requiring an outer try block to handle any errors in that case.

@yaakov-h

Your example only breaks if we remove brackets from try/catch. Again, that is not my goal here.

While I will concede that the savings are minimal, I argue that there is no downside to the approach aside from (minimal) additional complications to the language. Effectively, we could get this monstrosity:

try using (Foo bar = new Foo()) switch (bar.getFooBar())
{
    case Foo.Rod:
        break;

    case Foo.Stick:
        break;
}
catch (Exception ex)
{
}

The heart of the issue is being able to re-use existing syntax of statements like try and switch.

[DaZombieKiller]

If the issue is the extra level of nesting, then why not use a using declaration?

try
{
    using var db = new DatabaseInterface();
    db.Connect();
    db.DoSomeStuff();
}
catch (Exception ex)
{
    Log("Database failed to DoSomeStuff: {0}{1}", ex.Exception, ex.StackTrace);
}

[heaton84]

@DaZombieKiller
I was not aware that was in the pipeline. Thanks for the lesson. When was that introduced? I can't find anything in the documentation.

[DaZombieKiller]

@heaton84 It's a C# 8 feature: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#using-declarations