Hacker News Reader

Comment by ChrisSD | Hacker News Reader

Depends what exactly you're looking to do. You can propagate errors with the `?` operator. And you can match on the specific error at a higher level.

The docs[0] do give a more complex example of error matching:

    fn main() {
        let f = File::open("hello.txt");

        let f = match f {
            Ok(file) => file,
            Err(error) => match error.kind() {
                ErrorKind::NotFound => match File::create("hello.txt") {
                    Ok(fc) => fc,
                    Err(e) => panic!("Tried to create file but there was a problem: {:?}", e),
                },
                other_error => panic!("There was a problem opening the file: {:?}", other_error),
            },
        };
    }

Although they also provide a slightly simpler alternative for this particular case.

[0] https://doc.rust-lang.org/stable/book/ch09-02-recoverable-er...

View on HN

Doesn't look that much cleaner than try/catch, to be honest.

What I would really like to see in C#:

  public int DoThing(int y) 
  {
    //logic
  } 
  catch (SomeException e)
  {
    //handle things
    return 0;
  }

This would remove a lot of useless syntactic garbage without the need for any radical changes in the language. (It would translate to try-catch that wraps the entire body of the method.)

But so far I gave up on syntax-level error handling of any complexity. Generally, I just write multiple "agents" and all the error handling, retries and recovery is simply done by separate agent(s). The agent that tries to perform the initial actions simply records that it failed in some persistent storage and terminates or goes on to do something else.

> 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, and that can introduce other complexities, e.g. how to limit scope so that some things are inaccessible to the catch block.

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.

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