> A possibly better idea would be to report the line and column number. That should uniquely identify which code caused the problem, both for nil pointer and indexing. The question is how much additional space it would take to encode column numbers.
I like this idea a lot though I admit that it probably wouldn't be worth a significant increase in binary size. Would doing this mean holding two integers (line, column) in the binary for every dereference? I could definitely see that getting expensive. > You can almost always disambiguate the problem dereference with some judicious uses of \n, if the problem is reproducible. This is the solution I've come up with too :) It usually is good enough, just not for those rare but nasty situations where a panic only happens occasionally and in production. Thanks for the insight! On Fri, Feb 8, 2019 at 8:10 PM 'Keith Randall' via golang-nuts < golang-nuts@googlegroups.com> wrote: > 27605 is more about providing the values that caused the panic, not the > source location. It is still the case that even with 27605 multiple > indexing operations on the same line are not distinguished (unless > knowledge of the application lets you disambiguate using the values). > For nil pointer dereferences, there's no value to report. Or, there's > exactly one value to report, which isn't helpful. > > Mentioning the variable is problematic for the reason you mentioned. > > A possibly better idea would be to report the line and column number. That > should uniquely identify which code caused the problem, both for nil > pointer and indexing. The question is how much additional space it would > take to encode column numbers. > You can almost always disambiguate the problem dereference with some > judicious uses of \n, if the problem is reproducible. > > On Thursday, February 7, 2019 at 4:36:01 PM UTC-8, Tyler Compton wrote: >> >> After reading https://golang.org/issues/27605 (proposal: report indexes >> for bounds failure), I started to wonder why we don't do something similar >> with nil pointer dereferences. >> >> I've more than once found myself in a situation where I'm inspecting a >> nil pointer dereference panic and it ends up on a line where any number of >> variables could have been the nil pointer in question. It would be helpful >> in these circumstances to get a message like "attempt to dereference >> variable 'myvar', which is a nil pointer" or something along those lines. >> Here is a toy example that causes a panic on a line where there are many >> variables that could have been the problematic nil pointer. >> https://play.golang.com/p/mmkOOU3M3lU >> >> My guess as to why I've never seen this in a language before is because >> dereferencing doesn't always happen on a named variable. For example, >> `getSomePointer().field` could result in a nil pointer dereference, but >> there's no variable name to put in the panic. Maybe then the panic message >> would be "attempt to dereference anonymous variable, which is a nil >> pointer", which is still slightly less ambiguous than the current panic >> message. Do you think a feature like this could be useful, even with its >> inherent limitations? >> > -- > 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.
