FAQ
I like the extra security I get from the compiler when I do something like
this:

foo, err := Bar()

There're a few cases where the compiler comes to the rescue:

* I forgot to do something about it: I get "declared and not used" from go
* I forgot it can fail I might get a "multi-value in single-value context"
error
* If I decide it's not an important error I can explicitly ignore it with a
blank identifier

The code feels much more robust compared to Java's unchecked exceptions or
C's return codes but I can still screw up if I'm working with a function
that solely returns an error and I forget to do something with it:

err := Baz()
Baz()

In the rare cases where the second case is legitimate, the _ could just be
used instead. Are there any reasons the compiler lets me get away with
ignoring return values?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jérôme Champion at Jan 6, 2014 at 12:51 pm
    In
    foo, err := Bar()
    the fact that it force you to check the error is a side-effect:
    a) if you retrieve values, then you must retrieve them all. b) you cannot
    have an unused variable.

    Calling only Bar() ( even if the function has two return parameter ) would
    not trigger an compiler error.
    That's why the compiler lets you get away with ignoring return values. It's
    just not in the spec.

    But like you I like this functionality. Perhaps it could be implemented in
    a go tool where it could configured.
    Because I'm not really sure that I would like to check every call to
    fmt.Println for example.

    Le lundi 6 janvier 2014 11:12:41 UTC+1, jon...@gmail.com a écrit :
    I like the extra security I get from the compiler when I do something like
    this:

    foo, err := Bar()

    There're a few cases where the compiler comes to the rescue:

    * I forgot to do something about it: I get "declared and not used" from go
    * I forgot it can fail I might get a "multi-value in single-value context"
    error
    * If I decide it's not an important error I can explicitly ignore it with
    a blank identifier

    The code feels much more robust compared to Java's unchecked exceptions or
    C's return codes but I can still screw up if I'm working with a function
    that solely returns an error and I forget to do something with it:

    err := Baz()
    Baz()

    In the rare cases where the second case is legitimate, the _ could just be
    used instead. Are there any reasons the compiler lets me get away with
    ignoring return values?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamás Gulácsi at Jan 6, 2014 at 4:45 pm
    Check out on errcheck on github.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 6, '14 at 10:12a
activeJan 6, '14 at 4:45p
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase