Hacker News Reader

Comment by gambler | Hacker News Reader

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.

View on HN

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.

>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.

Reply on news.ycombinator.com