4 ms·

True, but I consider this the same idea. If you look up the API of a method and see an "error" return type, it is your responsibility to handle it, and you're v

True, but I consider this the same idea. If you look up the API of a method and see an "error" return type, it is your responsibility to handle it, and you're very encouraged to do so.

pcwalton 13y ago
I'm confused as to what you mean by "the compiler forces you to handle errors", then. Do you just mean that errors are documented?
- hornetblack 13y ago
  If I attempt to grab the result of a function eg: f := os.Create(fname) defer(f.Close()) It won't compile as `os.Create` returns `(file, error)`. So you must either: // Proper error handling f, err := os.Create(fname) if err != nil { log.Fatalf("Could not create '%s'", fname) // Well may want to do something other than crash. } defer(f.close()) If you ignore the error it's obvious f, _ := os.Create(fname) defer(f.Close()) It's like doing this in Java File f; try { f = new File(fname); } catch (Exception e) { // Ignore Exception }
  - drbawb 13y ago
    Possibly worth pointing out to non-gophers: in `Go` it is illegal to declare an unused variable. So if you write `f, err := os.Create("/bad/path");`, and that is the first time `err` has been declared & used in that scope, you can't just let `err` go unused or your program won't compile.
- elithrar 13y ago
  The quotes don't make any sense: mitchellh didn't say that at all.
  - Locke1689 13y ago
    Eh. He said, The PRIMARY reason Go is so reliable is also a reason many people hate go: you _have_ to handle every error. If the compiler isn't enforcing it, you don't have to do anything. At best you can say the language suggests it, but if there isn't even a warning I don't see how that's different from pretty much every typed language.
    - drbawb 13y ago
      >isn't even a warning This is actually enforced [in some cases] as a compile-time error. (BTW the `gc` family of Go compilers don't have warnings.) The two errors in particular that help trap this are: 1. All declared variables must be used. 2. All return values must be assigned to a variable. (Go allows for multiple return values from a function.) --- Idiomatically one would store [one or more] return values from a function with a short-form declaration (`:=`) which declares and assigns the LHS to the RHS. `a,err := someFunc()` where `someFunc()` returns `(SomeType, error)` declares and assigns `a int` and `err error`. If you declare `a,err := someFunc()` and do not use `a` or `err` elsewhere in scope, your program simply won't compile. The only way to squelch that error is to either use the variables OR you can use a `_` on the LHS. (Which makes an "assignment" to a blank identifier, e.g: discards the value.) --- An example of where this _wouldn't_ be enforced by the compiler is if you've declared [and used] `err` elsewhere in the scope and you are _reusing_ the identifier. For e.g: if you declared, assigned, used, and reassigned `err`. The compiler won't force you to use it _after_ the second assignment, so that second assignment could go untrapped with no complains from the compiler.
deleted 13y ago
[deleted]
twotwotwo 13y ago
I'd love it if "go vet" or something complained about implicitly discarded errors. If you mean to ignore an error, you can always assign to _.
- twotwotwo 13y ago
  Below, mseepgood pointed out https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck exists--looks excellent. (Still would be cool if the Gophers put something like it in the std distro.)

True, but I consider this the same idea. If you look up the API of a method and see an "error" return type, it is your responsibility to handle it, and you're very encouraged to do so.

pcwalton 13y ago

I'm confused as to what you mean by "the compiler forces you to handle errors", then. Do you just mean that errors are documented?

hornetblack 13y ago
If I attempt to grab the result of a function eg: f := os.Create(fname) defer(f.Close()) It won't compile as `os.Create` returns `(file, error)`. So you must either: // Proper error handling f, err := os.Create(fname) if err != nil { log.Fatalf("Could not create '%s'", fname) // Well may want to do something other than crash. } defer(f.close()) If you ignore the error it's obvious f, _ := os.Create(fname) defer(f.Close()) It's like doing this in Java File f; try { f = new File(fname); } catch (Exception e) { // Ignore Exception }
- drbawb 13y ago
  Possibly worth pointing out to non-gophers: in `Go` it is illegal to declare an unused variable. So if you write `f, err := os.Create("/bad/path");`, and that is the first time `err` has been declared & used in that scope, you can't just let `err` go unused or your program won't compile.
elithrar 13y ago
The quotes don't make any sense: mitchellh didn't say that at all.
- Locke1689 13y ago
  Eh. He said, The PRIMARY reason Go is so reliable is also a reason many people hate go: you _have_ to handle every error. If the compiler isn't enforcing it, you don't have to do anything. At best you can say the language suggests it, but if there isn't even a warning I don't see how that's different from pretty much every typed language.
  - drbawb 13y ago
    >isn't even a warning This is actually enforced [in some cases] as a compile-time error. (BTW the `gc` family of Go compilers don't have warnings.) The two errors in particular that help trap this are: 1. All declared variables must be used. 2. All return values must be assigned to a variable. (Go allows for multiple return values from a function.) --- Idiomatically one would store [one or more] return values from a function with a short-form declaration (`:=`) which declares and assigns the LHS to the RHS. `a,err := someFunc()` where `someFunc()` returns `(SomeType, error)` declares and assigns `a int` and `err error`. If you declare `a,err := someFunc()` and do not use `a` or `err` elsewhere in scope, your program simply won't compile. The only way to squelch that error is to either use the variables OR you can use a `_` on the LHS. (Which makes an "assignment" to a blank identifier, e.g: discards the value.) --- An example of where this _wouldn't_ be enforced by the compiler is if you've declared [and used] `err` elsewhere in the scope and you are _reusing_ the identifier. For e.g: if you declared, assigned, used, and reassigned `err`. The compiler won't force you to use it _after_ the second assignment, so that second assignment could go untrapped with no complains from the compiler.

deleted 13y ago

[deleted]

twotwotwo 13y ago

I'd love it if "go vet" or something complained about implicitly discarded errors. If you mean to ignore an error, you can always assign to _.

twotwotwo 13y ago
Below, mseepgood pointed out https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck exists--looks excellent. (Still would be cool if the Gophers put something like it in the std distro.)