5 ms·

> Well you should handle the error in the first place. That's like saying you should just write bug-free code in the first place.

• Karunamon 7y ago
  Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.
  • hota_mazi 7y ago
    Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.
    • Sphax 7y ago
      > The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". Where did you see that ? because that's not been my experience at all, and I've looked at a lot of Go code.
    • shazow 7y ago
      > Go does absolutely nothing to ensure you handle the error. Go has many community linters available, https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck is popular for checking unhandled errors. If you'd like a combo-pack, check out https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint which includes all of the popular linters in a configurable way.
      • apta 7y ago
        Those linters won't catch everything. There are cases that will slip by. Rust's error handling, as well as exceptions are both strictly superior to golang's error handling.
    • Thaxll 7y ago
      This is fud, I've never seen in Go code people dropping the err with _. The reason why you don't see that is because you have to be explicit about that, it's not something you forget it's done on purpose which obviously no one does.
      • apta 7y ago
        Just because you haven't seen it doesn't mean it doesn't exist. It's very easy to mishandle errors in golang, I've seen it several times now.
  • AnimalMuppet 7y ago
    And there's a reason why empty catch blocks in Java are an anti-pattern.
  • marwatk 7y ago
    If multiple functions you call return an error golang only cares if you've checked the last one.
    • Karunamon 7y ago
      Holy crap, seriously? I guess that makes sense since everyone calls the return 'err', I'd just never noticed before.
      • masklinn 7y ago
        Yup, the compiler is perfectly happy with a, err := Foo() b, err := Bar() c, err := Baz() check(err) doSomethingWith(a, b, c) because "err" is ultimately used so doesn't trigger the "unused variable" compile error. The Go compiler doesn't care that it's written to thrice and only checked once. In fact thinking about it that's a perfect example of "solving 90% of the problem, badly" the article talks about (though it's probably closer to 70% here): the Go compiler doesn't really try to understand that errors are a thing and are relevant. To avoid developers writing val, err := Foo() then going on to use `val` without checking `err` the devs decided to… require using variable. This solves that specific issue but does nothing if, say, you miss that the function returns just an error, or you don't care about the result so you just ignore everything it returns. Or as above if you've got multiple calls binding to the generic (and conventional) `err` and think to check the last one (possibly because the calls above were only added later and the compiler never complained). Meanwhile it makes Go throw a fit and literally refuse to compile your code because you wrote an innocent: val := 5 and hadn't come around to use it yet, or removed the one print you didn't care for anymore.
  • pcwalton 7y ago
    Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.
    • Thaxll 7y ago
      I'm no Rust expert, but Rust doesn't enforce that either. There is no language that enforce error checking afaik.
      • typon 7y ago
        You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
        • Thaxll 7y ago
          I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
          • typon 7y ago
            It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)
            • cjhopman 7y ago
              That's is completely false, stop spreading misinformation. This code will compile (see https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=050a528df9eecdadf6f65c58d59f62ba https://play.rust-lang.org/?version=stable&mode=debug&editio...): pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { foo(); Ok(()) } It will provide a warning, but there's a ton of stuff in c++ that would throw a warning and you wouldn't say that it "will not compile". A trivial change that still doesn't handle the error would get rid of the warning. pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { println!("{:?}", foo()); Ok(()) }
  • apta 7y ago
    No it won't: fmt.Println("foo") You're not forced to handle the error. Not to mention more obscure cases like a, err1 := foo() if err1 != nil { return err1 } b, err2 := bar() if err2 != nil { return err1 } // bug
  • acdha 7y ago
    I’ve never looked at a Go codebase where someone has handled every single error – it’s just too easy to assign it but not check the value. For a language which refuses to compile if you have an unused import, it seems like an odd gap not to have the compiler force you to access the error before it’s reassigned.