6 ms·

> unless you check the error return code of practically every statements Yes, you MUST. That is just how Go does things. If you don't do this, then of course t

> unless you check the error return code of practically every statements Yes, you MUST. That is just how Go does things. If you don't do this, then of course things are going to blow up at runtime. Your "unless" is the same as saying in a language like Java: unless you rescue the exceptions, the program crashes! Yes, clearly. Personally, I love Go's error handling. I made a joking tweet one time that over 10% of all lines of code in Packer are "if err != nil". That is still probably true, but I don't think its a bad thing. We also make Serf, which is powering some pretty large infrastructures out there, and we've never ONCE had a crash in production. Not once. We've had errors, but they were logged and handled. I attribute this to the fact that we were forced to handle every error. Some people like exceptions, but I've always liked Go's way of things in this department.

khyryk 13y ago
In my opinion, it should be a compile error to ignore return values without explicitly throwing them away with _.
- Dobbs 13y ago
  errcheck will add this as an optional linter. I've adjusted the git hooks on my machine to run errcheck and fail the commit if it doesn't pass (unless I specifically disable it).
- aaronblohowiak 13y ago
  add https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck to your continuous integration process.
lmm 13y ago
If 10% of your lines are repetitions of the same thing that's absolutely a problem with the language. You should find a more concise way to express the same thing (e.g. error monad).
- wting 13y ago
  To expand, Go's type system is relatively rudimentary. The lack of option types[0] leads to this fairly common, verbose Go pattern: func DoFoo(Foo foo) Cat { bar, err := GetBar(foo) if (err != nil) { return nil } baz, err := GetBaz(bar) if (err != nil) { return nil } cat, err := GetCat(baz) if (err != nil) { return nil } return cat } Option types add metadata to a type, essentially combining `bar` and `err` into a single variable. Let `Maybe x` mean a function will return `Something x` or `Nothing`. For example (in hypothetical Go): func DoFoo(Foo foo) Maybe Cat { bar := GetBar(foo) if (bar.(type) == Nothing) { return Nothing } baz := GetBaz(bar) if (baz.(type) == Nothing) { return Nothing } cat := GetCat(baz) if (cat.(type) == Nothing) { return Nothing } return cat } Since this is such a common pattern, Haskell has a bind operator (`>>=`) to take advantage of option types by passing the output as the input of the next function if it's a `Something`, or return `Nothing`. func DoFoo(Foo foo) Maybe Cat { return GetBar foo >>= GetBaz >>= GetCat } If you care about why something failed, use an `Either` instead of a `Maybe`. In a language that supports algebraic data types, you could create your own sum type instead. [0] https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type
  - jbooth 13y ago
    Now you've got way less code, and way more cognitive load per line. There's a reason why hideous Java is so successful while beautiful Haskell is a punchline to jokes.
    - wting 13y ago
      Many languages besides Haskell have option types (Rust, Scala, OCaml, Java 8): http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html http://www.oracle.com/technetwork/articles/java/java8-option... Using option types produces more robust code and prevents null pointer exceptions / segfaults. Go's idiom of multiple return values and error is a poor man's Either, which is an improvement on C's return code idiom[0]. [0] C's return code idiom led to the latest GnuTLS bug: http://blog.existentialize.com/the-story-of-the-gnutls-bug.html http://blog.existentialize.com/the-story-of-the-gnutls-bug.h...
awj 13y ago
> Yes, you MUST. That is just how Go does things. If it's something I "must" do, why doesn't the language force it to happen? Silent failure is a really bad default.
- AnimalMuppet 13y ago
  You mean something like Java's checked exception? That has its value, but you have some programmers who write empty catch blocks just to get rid of the exception. Forcing the programmer to handle it is not the same as forcing the programmer to handle it.
  - hackinthebochs 13y ago
    How is this an argument for silently failing being superior? It seems like static checked exception handling could solve this problem easily, the compiler can just display a warning on an unhandled exception and then pass it up the chain.
    - AnimalMuppet 13y ago
      It's not an argument for silently failing being superior. It's a claim that too often, static checked exception handling gets subverted, and therefore doesn't work. Sooner or later, you have to trust the programmer to not be an idiot. If he/she is an idiot, the language can try to help, but can't really fix it. Static checked exceptions let the programmer know that there's something that needs to be handled. That's good. It can check that the programmer put a catch block somewhere, but it can't guarantee that the programmer did anything appropriate to handle the problem inside that block. It's better than nothing, but it's not enough. (And if you're going to ask what is enough, I have to reply: Nothing. If the programmer is determined to ignore the fact that there's an error to handle, the language can't fix things.)
  - awj 13y ago
    I can see what you're saying, but ultimately there's no helping people who are doing something they don't really understand. I'm more interested in language features that remind me when I forget to do something I wanted to do.
copergi 13y ago
>Your "unless" is the same as saying in a language like Java And "our language is just bad as java" is a pretty awful sales pitch. >That is still probably true, but I don't think its a bad thing. No it is not a bad thing. It is a terrible thing. >I attribute this to the fact that we were forced to handle every error. But you aren't forced, that's the problem. >Some people like exceptions, but I've always liked Go's way of things in this department. Some people like proper error signaling and handling instead of either of the broken choices you suggest.

khyryk 13y ago

In my opinion, it should be a compile error to ignore return values without explicitly throwing them away with _.

Dobbs 13y ago
errcheck will add this as an optional linter. I've adjusted the git hooks on my machine to run errcheck and fail the commit if it doesn't pass (unless I specifically disable it).
aaronblohowiak 13y ago
add https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck to your continuous integration process.

lmm 13y ago

If 10% of your lines are repetitions of the same thing that's absolutely a problem with the language. You should find a more concise way to express the same thing (e.g. error monad).

wting 13y ago
To expand, Go's type system is relatively rudimentary. The lack of option types[0] leads to this fairly common, verbose Go pattern: func DoFoo(Foo foo) Cat { bar, err := GetBar(foo) if (err != nil) { return nil } baz, err := GetBaz(bar) if (err != nil) { return nil } cat, err := GetCat(baz) if (err != nil) { return nil } return cat } Option types add metadata to a type, essentially combining `bar` and `err` into a single variable. Let `Maybe x` mean a function will return `Something x` or `Nothing`. For example (in hypothetical Go): func DoFoo(Foo foo) Maybe Cat { bar := GetBar(foo) if (bar.(type) == Nothing) { return Nothing } baz := GetBaz(bar) if (baz.(type) == Nothing) { return Nothing } cat := GetCat(baz) if (cat.(type) == Nothing) { return Nothing } return cat } Since this is such a common pattern, Haskell has a bind operator (`>>=`) to take advantage of option types by passing the output as the input of the next function if it's a `Something`, or return `Nothing`. func DoFoo(Foo foo) Maybe Cat { return GetBar foo >>= GetBaz >>= GetCat } If you care about why something failed, use an `Either` instead of a `Maybe`. In a language that supports algebraic data types, you could create your own sum type instead. [0] https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type
- jbooth 13y ago
  Now you've got way less code, and way more cognitive load per line. There's a reason why hideous Java is so successful while beautiful Haskell is a punchline to jokes.
  - wting 13y ago
    Many languages besides Haskell have option types (Rust, Scala, OCaml, Java 8): http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html http://www.oracle.com/technetwork/articles/java/java8-option... Using option types produces more robust code and prevents null pointer exceptions / segfaults. Go's idiom of multiple return values and error is a poor man's Either, which is an improvement on C's return code idiom[0]. [0] C's return code idiom led to the latest GnuTLS bug: http://blog.existentialize.com/the-story-of-the-gnutls-bug.html http://blog.existentialize.com/the-story-of-the-gnutls-bug.h...

awj 13y ago

> Yes, you MUST. That is just how Go does things. If it's something I "must" do, why doesn't the language force it to happen? Silent failure is a really bad default.

AnimalMuppet 13y ago
You mean something like Java's checked exception? That has its value, but you have some programmers who write empty catch blocks just to get rid of the exception. Forcing the programmer to handle it is not the same as forcing the programmer to handle it.
- hackinthebochs 13y ago
  How is this an argument for silently failing being superior? It seems like static checked exception handling could solve this problem easily, the compiler can just display a warning on an unhandled exception and then pass it up the chain.
  - AnimalMuppet 13y ago
    It's not an argument for silently failing being superior. It's a claim that too often, static checked exception handling gets subverted, and therefore doesn't work. Sooner or later, you have to trust the programmer to not be an idiot. If he/she is an idiot, the language can try to help, but can't really fix it. Static checked exceptions let the programmer know that there's something that needs to be handled. That's good. It can check that the programmer put a catch block somewhere, but it can't guarantee that the programmer did anything appropriate to handle the problem inside that block. It's better than nothing, but it's not enough. (And if you're going to ask what is enough, I have to reply: Nothing. If the programmer is determined to ignore the fact that there's an error to handle, the language can't fix things.)
- awj 13y ago
  I can see what you're saying, but ultimately there's no helping people who are doing something they don't really understand. I'm more interested in language features that remind me when I forget to do something I wanted to do.

copergi 13y ago

>Your "unless" is the same as saying in a language like Java And "our language is just bad as java" is a pretty awful sales pitch. >That is still probably true, but I don't think its a bad thing. No it is not a bad thing. It is a terrible thing. >I attribute this to the fact that we were forced to handle every error. But you aren't forced, that's the problem. >Some people like exceptions, but I've always liked Go's way of things in this department. Some people like proper error signaling and handling instead of either of the broken choices you suggest.