On Sat, Jul 5, 2025 at 9:19 PM Ge <evergon...@gmail.com> wrote:
>
> Thanks Ian and Dominik for the tips. I have checked the issue 72860 and found
> randall77 posted a comment that
> I couldn't confirm from golang spec(go.dev/ref/spec):
>
> //https://github.com/golang/go/issues/72860#issuecomment-2734549770
> ```
>
> Where f returns a pointer and an error. f expects its callers to only use the
> ptr result if the error is nil. And in particular, f returns a nil pointer
> whenever it returns a non-nil error.
>
> This code is incorrect, in that it dereferences the ptr result before
> checking the error. The Go spec says that it should nil pointer panic if f
> returns a nil pointer and non-nil error.
>
> ```
>
> I did a search in whole spec and did't find any descriptions about it.
> From my understanding, `v, err := f()` is like `v1, v2 := f()` from
> compiler's view,
> checking error is user code's business logic and couldn't be assumed by
> compiler.
> If it's defined in spec, what about variants like `a, b, err := f()` or `a,
> b, err1, err2 := f()`？
It's true that for code like
f, err := os.Open("nonexist")
it's just a convention that if err != nil then f == nil. For example,
Google's Go style guide:
https://google.github.io/styleguide/go/decisions#returning-errors .
os.Open follows that convention.
Ian
--
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 visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXowfJUky8dDpPpST-frQCORWNApZycY-dMVYz3xC2_yQ%40mail.gmail.com.
