Implicit try scope when catch or finally block is given

[sdwatkinsdev]

It's not unusual for a method to contain a try/catch/finally that spans the whole method definition, like so:

public static void LoadThing()
{
    try
    {
        return LoadThingFromSomewhere();
    }
    catch (Exception e)
    {
        _logger.Warn("Couldn't locate the desired resource; falling back to default value");
        return new DefaultThing();
    }
}

This proposal would allow eliding the try and its braces (only catch is shown, but finally would be treated identically):

public static void LoadThing()
{
    return LoadThingFromSomewhere();
    catch (Exception e)
    {
        _logger.Warn("Couldn't locate the desired resource; falling back to default value");
        return new DefaultThing();
    }
}

Explicit try blocks would of course still be available, and the presence of one would limit the scope in which the catch would apply, just as it works today. The following would likely not be allowed, but I'd be interested to hear feedback:

public static void LoadThing()
{
    DoSomeSetup();

    try
    {
        DoMoreSetup();
    }
    catch (Exception e)
    {
        _logger.Warn("First thing failed");
        return new DefaultThing();
    }

    return DoFinalThing();

    catch (Exception e)
    {
        _logger.Warn("Second thing failed");
        return new DefaultThing();
    }
}

Specifically, when there's no statement between the earlier catch block and the method-level catch block, there would be a syntactic conflict with the already-existing multiple catch blocks feature, and if you're writing this kind of code you probably want maximum clarity about what can be caught where. But the simple case (with no other try/catch in the same scope) would cut down on boilerplate without sacrificing clarity.

[HaloFour]

I much prefer the explicitness of having the try block; you know exactly what it's going to do. Permitting the omission of that would make it more difficult to discern what the flow of the method is. And it could also easily lead to bugs in the implementation of the method, such as if someone adds argument validation after the fact and misses that there is a catch block somewhere at the bottom of the method.

[ActivistInvestor]

Compiler warning: 'direct throw from within a try block' (which I've seen some foolishly use as a form of control flow). As far as lack of explicitness goes, any code called from a try block could throw as well, which isn't obvious in any case. I agree that the lack of explicitness could be a source of confusion, in cases where the body of the member contains too much code (but that is a different problem).

[sdwatkinsdev]

If your method is long enough that the catch is not visible, you still would need to scroll down to see which exception types are being caught and how before you know what the flow of the method is and what it actually does, so I'm not sure if I agree with that concern. To be clear, the longer example above is not what I'm recommending, and was provided only to clarify the intended scope. But since this is only a suggestion to cut down boilerplate and increase the signal-to-noise ratio without adding anything truly meaningful to the language, I'm fine with keeping the status quo.