Personally, I'd argue that you are misattributing the root cause. The code you posted at least, does not check the error of ensureOpen. If it would have, then it wouldn't have crashed. It is pretty common in Go, to return a valid value if and only if no error is returned alongside it. It is also not uncommon for code to crash, if you use an invalid value. Note, that if between lines 12 and 13 you would've done anything else with the opened file, it also would've crashed - even if you would've returned an interface from NewCloser (as that would mean calling a method on a nil-interface).
Of course it would be better to have defense-in-depth, but IMO it does make this a somewhat weaker point in the question of zero-interfaces vs. zero-pointers (and FTR I'm still in favor of not reusing the same identifier for both in Go 2). FWIW, there is a linter that tries to find unhandled errors: https://github.com/kisielk/errcheck On Thu, Feb 15, 2018 at 11:01 PM Tarmigan <tarmigan+gol...@gmail.com> wrote: > We recently had a crash in our code because of an interface != nil > issue (covered in FAQ as https://golang.org/doc/faq#nil_error). > > The thing that made it more subtle than the typical error interface > case is that the assignment from a function returning a concrete type > was made to an interface field within a struct. If the function had > returned the same type as the field (either as an interface or > concrete type) then the crash would not have happened. A simplified > example is here: https://play.golang.org/p/8Xmj_LJY3yT > > The fix is easy enough, but now we need to go through our code and > audit all field assignments from functions to see if there is an > interface conversion. This could happen if refactoring from a > concrete type to an interface and would not be caught at compile time. > > Are there any vet or lint checks that would have caught that? If not, > my request is that a check for this be added to vet or lint because > this issue can be otherwise hard to find. > > Thanks, > Tarmigan > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
