@CriticalSilence I see your points, but personally they don't bother me. On the first one, people can (and do) already use try-catch too much. I don't really think this makes it all that much easier to misuse, but it's subjective and we may have to disagree on that.

On the second point, I view it as similar to the `using` and `namespace` declarations versus their statement equivalents. I will concede that the difference here is that the scope of the application can be foreshortened by a `catch` or `finally`, where `using` and `namespace` declarations are until the end of the method of file respectively. We seem okay with these not having a statement block with indented code, so why should `try` be different?

That last point begs a rebuttal that you could start levelling the same arguments for `if`, `else` and probably other constructs that are followed by statement blocks, and that would clearly be absurd. But I still think `try` is different enough that this would be okay.

@CriticalSilence Just for interest, the impetus for writing this proposal was that for the umpteenth time I found myself extracting the contents of one method into another so I could put a try...catch around the whole thing without indenting everything further. The context here is if *anything* goes wrong in the method, I need to stop the exception bubbling so I can return an explicit failure from the method and thereafter refund a payment. My default design position is top level exception handling, but there are some places where you do need different behaviour for resilience.