5 ms·

> But it doesn't take long to get used to it I did get used to it, but all the if err != nil { return nil, err } sometimes taking up half or more of

• ufmace 5y ago
  This exactly. I haven't written enough Go to be really annoyed by the more subtle things in the post, but it'd really be nice if they could come up with some syntax sugar for that kind of like Rust's ? helper. Maybe the Go ? is allowed within any function whose last return value is an error on any function call whose last return value is also an error. Call it with ? at the end and accept all but the last return value. At runtime, if the err is not nil, then it returns from the function, supplying the err value and nil for any other return values.
  • oefrha 5y ago
    https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf... I don’t think it went anywhere, unless I missed it.
• preseinger 5y ago
  Error handling being explicit isn't an eyesore. It lifts what is with exceptions a hidden control flow to the foreground.
  • __david__ 5y ago
    Explicit error handling isn't the complaint—3 vertical lines of error handling after every function call is. Rust, for instance, started this way and eventually introduced the `try!` macro and finally the `?` operator. It's still explicit, it just doesn't fill your screen with unuseful boilerplate.
    • preseinger 5y ago
      > unuseful boilerplate First, ..., err := process(...) if err != nil { return nil, err } is an unfortunately common antipattern. Errors should always be annotated, e.g. ..., err := process(...) if err != nil { return nil, fmt.Errorf("process: %w", err) } The extra lines carry no significant cost -- it's not like reading them imposes a burden versus parsing a single line dense with semantic information. They expose the `return` keyword, which clearly signals a control flow point that is hidden by method chaining and `?`. And it doesn't grant the error control flow special status! These are virtues. I don't see this as unuseful at all. It's fine if you do, of course! But there's not an objective ruling, here.
      • cy_hauser 5y ago
        So are you manually building a stack trace?
        • preseinger 5y ago
          In a sense, yes. But the outcome of this process is deliberate rather than mechanical. You choose how much information to expose to callers at each layer. You can display it to users, in a pinch.
• nvarsj 5y ago
  iferr is one of the worst warts of the language. I recently converted a Pulumi project from golang to Typescript. Code size dropped by 30% just by removing all the iferr checks. The other thing is the compiler doesn’t complain if you forget to check error returns - so it’s easy to make mistakes. This and lack of generics make golang incredibly verbose at times.