4 ms·

> It would translate to try-catch that wraps the entire body of the method It would not not be the same unless you change how scoping works in these instances,

• gambler 7y ago
  This: public void DoThing(){ //code } catch (Exception x){ } finally { } would simply be syntactic sugar for this: public void DoThing(){ try { //code } catch (Exception x){ } finally { } } It's consistent.
  • ilitirit 7y ago
    Yes, and that only works by changing how scoping works. Unless of course you don't care about the variables created inside. i.e. public void DoThing() { var someVar = SomeStaticClass.FooFunc(); someVar.DoSomething(); } catch (Exception x) { // Scoping rules will need to change // to put someVar in scope: _logger.Log($"{someVar.GetId()} is invalid"); } finally { someVar.Cleanup(); } And this also implies that there's no way to make a variable declared inside the method inaccessible to the catch block without additional changes to the language.
    • gambler 7y ago
      >Unless of course you don't care about the variables created inside. In majority of cases I really don't care about the variables created inside. If I can't handle an error just by looking at the exception and method arguments I usually refactor. In my view, error handling should not be intertwined with the "happy path". It makes reasoning about non-trivial code much harder. For other cases the old syntax will still be available. And yes, the value of "finally" in such a shorthand is dubious. I just added it to make it clear how the rewrite rule would work.