Oh, and I just realized I linked completely the wrong issue. Here is a good link: https://golang.org/issues/30116
On Sat, Feb 9, 2019 at 10:31 AM Tyler Compton <[email protected]> wrote: > > 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 < > [email protected]> 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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
