runtime: confusing stack trace in case of deferring <nil> function

[snakeru]

Deferring a nil function pointer produces a stack trace that does not mention the deferred function. This could be quite time-consuming to debug in case of, say, this use case:
cancel, err := Open(ctx)
if err!=nil {
log.Error(err)
// note that I forgot to put 'return' in here
}
defer cancel()
// many lines of code here
return nil

The snippet above will generate a panic() pointing to the 'return nil' line as the last line of user code.
Perhaps the error message could be improved.

Example: https://play.golang.org/p/jx3SBaSNlt
Current stack trace:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0xffffffff addr=0x0 pc=0x93074]

goroutine 1 [running]:
panic(0x13f3e0, 0x1040a038)
/usr/local/go/src/runtime/panic.go:481 +0x700
main.a(0xfef70018, 0x1040a120)
/tmp/sandbox234618258/main.go:11 +0xfb
main.main()
/tmp/sandbox234618258/main.go:15 +0x20

[snakeru]

Here is the function for the stack trace above:

[davecheney]

Thanks for your error report. Can you please tell us the version of Go you
are using.

On Wed, 27 Apr 2016, 19:15 Alexey Nezhdanov, notifications@github.com
wrote:

Here is the function for the stack trace above:
[image: image]
https://cloud.githubusercontent.com/assets/72657/14847515/494a9e66-0c69-11e6-91c9-7299de345f89.png

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#15466 (comment)

[snakeru]

The play.golang.org (used to create this thread) reports version "go1.6.2".

[davecheney]

Thank you. I've confirmed that with 093ac15 the backtrace message also
blames line 11.

On Wed, Apr 27, 2016 at 8:58 PM, Alexey Nezhdanov notifications@github.com
wrote:

The play.golang.org (used to create this thread) reports version
"go1.6.2".

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#15466 (comment)

[randall77]

Reporting line 11 is correct. A while ago we had a debate about whether defer of nil should panic at the defer statement, or panic at the end of the function. We decided on the latter. Lots of discussion at #8107 and related issues (#8109, #8045, #8047).