> 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.

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.

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.

I also generally think that writing boilerplate code is unproductive - golang's error system relies on people pedantically writing boiler plate code constantly among their logic - the result is to obscure the actual logical drive of the code.

I'm no Rust expert, but Rust doesn't enforce that either.

There is no language that enforce error checking afaik.

You get a compiler warning.

You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.

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?

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)

That's is completely false, stop spreading misinformation.

This code will compile (see 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(())
  }

I wonder if people upthread meant the warning, or e.g. getting the `Foo` in `Result<Foo, BarError>`.

(EDIT: nevermind, just looked again and pcwalton was referring to the warning and specifically `Result<(), E>`; oh well)

Because the latter is impossible in Rust and probably more relevant to the usual cited issue with Go's pair approach (i.e. using the null/zeroed `Foo` without checking if there was an error).

I do agree though that the warning isn't to stop you from not handling the error at all, it's more of a hint that maybe you forgot something.

Printing a `Result` may be the legitimate way to handle it in that case, it's largely left to the user to decide what propagates and what doesn't.

All languages which uses Result or Either types...?

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

If multiple functions you call return an error golang only cares if you've checked the last one.

Holy crap, seriously? I guess that makes sense since everyone calls the return 'err', I'd just never noticed before.

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.

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.

> 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.

> Go does absolutely nothing to ensure you handle the error.

Go has many community linters available, 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 which includes all of the popular linters in a configurable way.

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.

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.

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.

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.

And there's a reason why empty catch blocks in Java are an anti-pattern.

The language should make you handle the error and the compiler should refuse to compile your code until you have done so.

Sorry, can't do that, too hard.

We will make sure you remove that innocent unused import though, can't have those lying around being all importey.

So checked exceptions, then?

That's one way, yes.