Re: [go-nuts] Re: Providing more detail after a nil pointer dereference

2019-02-09 Thread Tyler Compton
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 wrote: > > A possibly better idea would be to report the line and column number. > That should uniquely identify which code caused the

Re: [go-nuts] Re: Providing more detail after a nil pointer dereference

2019-02-09 Thread Tyler Compton
> 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 pr

[go-nuts] Re: Providing more detail after a nil pointer dereference

2019-02-08 Thread 'Keith Randall' via golang-nuts
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 der