Implicit try block with finally/catch clause

[ActivistInvestor]

Not sure how to find out if this has been proposed already or not, but...

I would like to see support for implicit outer-most try/catch/finally blocks in the body of a method or function, wherein a finally and/or catch clause could appear without a try block, making the code that precedes either the catch or finally clause implicitly a try block, extending from the start of the method's body.

In other words:

public static bool SomeMethod()
{
   try
   {
      DoSomething();
      DoSomethingElse();
      return true;
   }
   catch(System.Exception ex)
   {
      HandleException(ex);
      return false;
   }
   finally
   {
      CleanUp();
   }
}

Could be expressed as:

public static bool SomeMethod()
{
   DoSomething();
   DoSomethingElse();
   return true;
   catch(System.Exception ex)
      HandleException(ex);
      return false;
   finally
      CleanUp();
}

The implied try{} block extends from the start of the
method, up to the first catch or finally 'statement'.

The try, catch and finally blocks are implicitly-
delimited, requiring no braces. The catch block
extends to either a finally 'statement' or the end
of the method body. The finally block extends to
the end of the method body.

The purpose served is to minimize the complexity of
retrofitting a try/catch/finally into existing code.

[siegfriedpammer]

Similar ideas:
#908
#968
#7127

And there are even more...

[colejohnson66]

If your goal is to remove a level of indentation, use seperate functions:

public static bool SomeMethod()
{
    try
    {
        SomeMethodCore();
        return true;
    }
    catch (Exception ex)
    {
        HandleException(ex);
        return false;
    }
    finally
    {
        CleanUp();
    }
}

private static void SomeMethodCore()
{
    DoSomething();
    DoSomethingElse();
}

The try, catch and finally blocks are implicitly-delimited, requiring no braces.

Why? C# is not Python.

[CyrusNajmabadi]

Right. I've given a reason for why I don't think that's a good idea. The symmetry here of all the sections is desirable. As is making try explicit at the start.

[ActivistInvestor]

In that case I think that we will just agree that we disagree on that.

Your points remind me of the many debates and discussions on LISP, and specifically how much opposition there was to the 'super-parentheses' (a "]" that closes any number of open parens) . Most of the arguments against it were founded on its lack of 'symmetry'. But that was a long time ago.

[CyrusNajmabadi]

Your points remind me of the many debates and discussions on LISP, and specifically how much opposition there was to the 'super-parentheses

Right. Style is very important to a language. Attempting to add forms to a language that stylistically clash is not likely to be successful, or well received.

[ActivistInvestor]

And I think that's where we disagree. Style is dictated to a great extent by language syntax and semantics.- That's a chicken/egg thing.

[CyrusNajmabadi]

When I say "style", I literally mean syntax.

[Jeltz191]

We could adjust your idea to leverage the using keyword to ensure that catches apply just to the scope of the using code?:
using catch(Exception c) =>UserCatchMethod(c)
using finally=>UserFinalCode();

[ActivistInvestor]

I would find this a good alternative, except that 'using' might cause some confusion with its current definition. The original though was that try/catch/finally are implicitly delimiting the code blocks that appear between them. I think that could only work at the outermost level of a body of code.

[theunrepentantgeek]

The try, catch and finally blocks are implicitly-delimited, requiring no braces.

Or, put another way ...

The try, catch and finally blocks are implicitly-delimited, requiring any developer reading the code to stop and puzzle through to work out the scopes.

Explicit braces are straightforward to understand and brook no ambiguity about the actual scope. This is a good thing, not a problem that needs to be solved.

Trivial examples aside, production code is hard enough to understand as it is - I don't understand why it's a good idea to make it harder to read.

[ActivistInvestor]

You're failing to consider the circumstances under which The Proposal I made would be used. Typically it would involve a single statement in the try block and a single statement in the finally or catch block.

[CyrusNajmabadi]

@ActivistInvestor please keep things civil

[theunrepentantgeek]

Typically it would involve a single statement in the try block and a single statement in the finally or catch block.

That's how you're thinking of it, sure.
But is it realistic to assume that any developer using this feature would share the exact coding style as yourself?

Anyone that is incapable of figuring that out with an implicit block ...

I'm sure almost any developer would be able to work it out if they gave it their entire attention.

However, I don't think that is at all likely. A developer coming in to read the method doesn't arrive with the thought "I've got to work out how the implicit scopes work", they arrive with "Why on earth does this code do THAT odd things that's caused an outage?" - or some similar high level goal.

They shouldn't have to down tools and spend time puzzling through the code, just because someone decided a single level of indentation was a problem.