FAQ
As has been discussed quite a bit lately, nil values do not always end up
as nil interfaces. Some background:
http://golang.org/doc/go_faq.html#nil_error. There are practical reasons
for this, with practical applications as well, but the issue with this is
that it can happen implicitly without the programmer ever noticing. A
solution to this could be an addition to the "go vet" tool, where any cases
that a pointer value could be unassigned and later be converted to an
interface value, the conversion must be explicit. Vet could also explain
why you must explicitly convert, pointing to documentation on interface
values.

A small example:

func PotentialNonNilError() error {
var err *SomeError
if some case {
err = SomeError{"bad things happened."}
}
// With err potentially undefined, we must explicitly convert to error, and
so
// the user acknowledges that this may return a non-nil interface value.
return error(err)
}

P.S. It could be nice to eventually introduce something like this as an
error in the compiler when such compatibility breaking changes occur.

--

Search Discussions

  • James Gray at Oct 10, 2012 at 11:12 pm
    Hmm, no comments at all. I don't know if it is worth opening an issue or
    not.
    On Monday, October 1, 2012 4:15:21 PM UTC-5, James Gray wrote:

    As has been discussed quite a bit lately, nil values do not always end up
    as nil interfaces. Some background:
    http://golang.org/doc/go_faq.html#nil_error. There are practical reasons
    for this, with practical applications as well, but the issue with this is
    that it can happen implicitly without the programmer ever noticing. A
    solution to this could be an addition to the "go vet" tool, where any cases
    that a pointer value could be unassigned and later be converted to an
    interface value, the conversion must be explicit. Vet could also explain
    why you must explicitly convert, pointing to documentation on interface
    values.

    A small example:

    func PotentialNonNilError() error {
    var err *SomeError
    if some case {
    err = SomeError{"bad things happened."}
    }
    // With err potentially undefined, we must explicitly convert to
    error, and so
    // the user acknowledges that this may return a non-nil interface value.
    return error(err)
    }

    P.S. It could be nice to eventually introduce something like this as an
    error in the compiler when such compatibility breaking changes occur.
    --
  • Jan Mercl at Oct 11, 2012 at 9:26 am

    On Thu, Oct 11, 2012 at 12:15 AM, James Gray wrote:
    Hmm, no comments at all. I don't know if it is worth opening an issue or
    not.
    IMO, just write the idiomatic version:

    func Whatever() (err error) {
    if some case {
    err = &SomeError{"bad things happened."}
    // return &SomeError{"bad things happened."}
    }
    ...

    return
    }

    -j

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 1, '12 at 9:25p
activeOct 11, '12 at 9:26a
posts3
users2
websitegolang.org

2 users in discussion

James Gray: 2 posts Jan Mercl: 1 post

People

Translate

site design / logo © 2021 Grokbase