Hacker News new | past | comments | ask | show | jobs | submit login

Sure, in an unrealistic subset of cases, try! can hide the mess. But these aren't fair, and especially nor is your comparison.

Any practical code using Results soon ends up wanting to mix the errors from multiple sources. This requires a lot of boilerplate effort to make everything interop, and the machinery to reduce this is both complex and not standardised. If you don't go the upfront boilerplate-and-machinery route, things look awful.

And of course, if you use something else, like an Option, you're back to

    let foo = match bar() {
       Some(foo) => foo,
       None => return None,
    };
Go is much more consistent, and less pathological.

Your example is especially disingenuous, though. For example, you chastise Go with

    defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled
but ignore the fact that this "bug" is nonoptionally hardcoded[1] into the Rust program. Which is it then?

Rust's error handling looks nice on fake examples, and manageable inside self-contained libraries. My experience of actually using multiple libraries is that Rusts error handling is a choice between tangly handling of nested errors or verbose attempts to early-exit.

[1]: https://github.com/rust-lang/rust/blob/master/src/libstd/sys...




Have you tried error-chain?


Kind'a proves the point, though, doesn't it? It's a complex and nonstandardized workaround of the kind Go explicitly tries to avoid.

As to specifically whether I have used error-chain, not really. I no doubt will in the future, but I'm not seeing Rust on my plate for a while.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: