I would like to share two posts from Cheney which could help you visualise situations of nil receivers, and if those should be checked or not by your program
https://dave.cheney.net/2013/01/19/what-is-the-zero-value-and-why-is-it-useful https://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t One of the previous examples given to you could be simply fixed by using the zero value of the type. It all boils down to how you want your program to behave and what you expect from it. Your question is about design and designing a program which intrinsically handles state without boilerplate code is a key. On Friday, November 26, 2021 at 8:46:42 AM UTC+1 axel.wa...@googlemail.com wrote: > In my opinion, this depends on exactly one thing: I nil is expected to be > a valid value (and I need to dereference it to implement that valid > behavior), I will check for nil to trigger that behavior. An example is a > linked list or tree data-structure, where calling a method on nil can > signal "end of list" and simplify code, e.g.: > https://go.dev/play/p/3iBnERuId_v > > Otherwise, I don't check. If nil is not an expected value, calling a > method on a nil-pointer is a bug and it will panic as soon as it is > dereferenced. Panicing on a bug is the correct behavior. Usually, there > isn't anything do to but panic in that case anyways - I could do `if p == > nil { panic("nil pointer") }`, but that doesn't add any benefit, the panic > will happen either way. > > Some people will advocate to return an error when calling a method on a > nil-pointer which doesn't expect that, if it already returns an error (and > letting it panic otherwise). Personally, I strongly disagree with this > philosophy. To me, a panic is meant to be communicated to the *programmer*, > to debug (and hence it produces a stacktrace), while an error is meant to > be communicated to the *user* of a program. In particular, an error should > be fixable without touching the program. "File config.json does not exist" > is a clear error, which the user of a program can interpret and fix and > which is not dependent on the internal validity of the program. "(*Foo).Bar > called on a nil-pointer" is something they can do nothing about - > especially not without a stack trace". Hence, returning an error on a > nil-pointer is converting a useful signal into a useless one, frustrating > both the user and the programmer, who has then to try and fix a bug, > without any debugging-context. > > On Fri, Nov 26, 2021 at 5:39 AM shinya sakae <sakashin...@gmail.com> > wrote: > >> Hi. >> I've been using Go for a while now, and I've noticed something. >> Do pointer receiver methods need to be checked for nil? >> In the standard package, it may or may not be checked. >> I'd like to hear your opinions. >> >> -- >> > 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/8bada92b-f179-4133-adcf-0cf971671b00n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/8bada92b-f179-4133-adcf-0cf971671b00n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0fe832a7-a3f0-4c1f-9d2d-4c8bea09f118n%40googlegroups.com.
