I rag on “if err != nil { return err }”, but I can sort of understand where people who prefer it to try/exceptions are coming from, even though I completely disagree. But I can’t even begin to understand people who prefer hand-written state machines to async/await.
-
-
Replying to @pcwalton
Whenever people talk Go's "readability", I can't get over how every line of actual code is buried in an additional 3+ lines of redundant error handling boilerplate. "...but you get used to it!" is the counterargument, and one I think can be used to justify anything as "readable"
4 replies 4 retweets 33 likes -
If you actually add some valuable context and not just "return err", it makes a lot of sense. I like it, because the control flow is so explicit.
1 reply 0 retweets 1 like -
1 reply 1 retweet 3 likes -
Wow, that is just ugly. That is not the price I'm going to pay for saving one line of code. I mostly use fmt.Errorf("failed to foo with bar: %s", err), which not only adds context, but at the same time, tells the reader what I was actually trying to do, thus documenting the code
1 reply 0 retweets 0 likes -
In Rust I can write try!(f(…).map_err(MyErr::FooFailed)); which is just as clear and shorter.
2 replies 0 retweets 2 likes -
In my experience over half the time errors can be propagated without additional context. So map_err is still more succinct for the cases where you want to add it, and then it's an even bigger win when you don't.
1 reply 0 retweets 2 likes
Yeah, I rarely ever bother. (Though GPU programming is a little weird because you can’t afford to synchronously check errors for performance reasons—error checking is an async operation. So I don’t actually deal with errors in Rust as much as others do nowadays.)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.