Re: [go-nuts] Do pointer receiver methods need to be checked for nil?

['Axel Wagner' via golang-nuts]

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 
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+unsubscr...@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
> 
> .
>

-- 
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/CAEkBMfGbTffrweW-Kjqj5ZyvrpTzXiwcRWeXcyy-Ct-o8NowGA%40mail.gmail.com.

Re: [go-nuts] Do pointer receiver methods need to be checked for nil?

[Roland Müller]

Definitely yes. I just sent a message in another thread in this discussion
group

BR,
Roland

Quoting myself:

Obviously, even just calling a "methods" of some struct instance that is
not initialized succeeds in Go. A panic occurs only when the program tries
to derefer nil pointer:

'func (ev *Event) do()' only uses the pointer but does not derefer it.
Thus, no panic.

Here 'func (ev Event) do2()' derefers nil pointer already before call.
Panic in main.main()

https://go.dev/play/p/O_C0RpXb46h

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x47f812]

goroutine 1 [running]:
main.main()
/tmp/sandbox1681946220/prog.go:14 +0x112


Here 'func (ev *Event) getS()' derefers the pointer. Panic happens inside
the main.getS()
https://go.dev/play/p/lto_JSFC2Qd

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x47f8d4]

goroutine 1 [running]:
main.(*Event).getS(0x4b2a40)
/tmp/sandbox1571083836/prog.go:35 +0x14



Am Fr., 26. Nov. 2021 um 06:39 Uhr schrieb shinya sakae <
sakashin10291...@gmail.com>:

> 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+unsubscr...@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
> 
> .
>

-- 
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/CA%2B8p0G02gUnphuyLMnuYk6De7RHao77jxVOq0cOLtMM7WCDDZA%40mail.gmail.com.

Re: [go-nuts] some incorrect code in blog.

[Roland Müller]

Hello David,

the behavior of File.Close() on nil was a surprise for me too.

Obviously, even just calling a "methods" of some struct instance that is
not initialized succeeds in Go. A panic occurs only when the program tries
to derefer nil pointer:

'func (ev *Event) do()' only uses the pointer but does not derefer it.
Thus, no panic.

Here 'func (ev Event) do2()' derefers nil pointer already before call.
Panic in main.main()

https://go.dev/play/p/O_C0RpXb46h

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x47f812]

goroutine 1 [running]:
main.main()
/tmp/sandbox1681946220/prog.go:14 +0x112


Here 'func (ev *Event) getS()' derefers the pointer. Panic happens inside
the main.getS()
https://go.dev/play/p/lto_JSFC2Qd

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x47f8d4]

goroutine 1 [running]:
main.(*Event).getS(0x4b2a40)
/tmp/sandbox1571083836/prog.go:35 +0x14


BR,

Roland



Am Do., 25. Nov. 2021 um 22:54 Uhr schrieb David Karr <
davidmichaelk...@gmail.com>:

> I meant, did you test it with a bad path, and with the defer before the
> error check?  I believe you implied that this didn't result in a failure.
> It would have happened on exit from the method, if anything.
>
> On Thu, Nov 25, 2021 at 12:49 PM Roland Müller  wrote:
>
>> Yes. Actually I only tested with a non-existing file.
>>
>> But if you mean that case were also the directory is missing: behavior is
>> still the same.
>>
>> BR,
>> Roland
>>
>> func main() {
>> f, err := os.Open("/tmp/dat_is_net_do/dat")
>> //defer f.Close()
>> fmt.Printf("%v\n", f)
>> if err != nil {
>>   fmt.Println("NO FILE")
>>   //return
>>}
>>defer f.Close()
>>fmt.Println("END")
>> }
>>
>>
>> Am Do., 25. Nov. 2021 um 21:43 Uhr schrieb David Karr <
>> davidmichaelk...@gmail.com>:
>>
>>> And did you test that with a file path that would fail?
>>>
>>> On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:
>>>
 Hello,

 actually trying this with os.Open() the program behaves the same
 regardless whether the defer is before or after the error handling, Thus,
 no panic :-)

 Isn't anything declared with defer always running after the user code
 in the given func ends? I am too tired now to look this up.

 BR,

 Roland

 package main

 import (
 "fmt"
 "os"
 )

 func main() {
 f, err := os.Open("/tmp/dat")
 //defer f.Close()
 fmt.Printf("%v\n", f)
 if err != nil {
   fmt.Println("NO FILE")
   //return
}
defer f.Close()
fmt.Println("END")
 }

 Output:
 
 NO FILE
 END


 On 11/25/21 10:19, Fannie Zhang wrote:

 OK, I see. Thank you.



 *From:* Kurtis Rader  
 *Sent:* Thursday, November 25, 2021 10:26 AM
 *To:* Fannie Zhang  
 *Cc:* golang-nuts 
 
 *Subject:* Re: [go-nuts] some incorrect code in blog.



 Notice the date of that blog article: 2010-08-04. It's more than eleven
 years old. Blog articles are not updated as the language changes. However,
 in this case the example in that article is correct. If `os.Open()` returns
 an error then the `src` return value is invalid.



 On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang 
 wrote:

 Hi all,



 There is some incorrect code in
 https://go.dev/blog/defer-panic-and-recover blog.



 The original code is

 *func CopyFile() {*

 *   ...*

 *   if err != nil {*

 *  return*

 *   }*

 *   defer src.Close()*

 *   ...*

 *}*



 I think the correct code should be

 *func CopyFile() {*

 *   ...*

 *   defer src.Close()*

 *   if err != nil {*

 *  return*

 *   }*

 *   ...*

 *}*



 I do not know how to modify the go blog, can anyone help? Thank you.



 Best regards,

 Fannie Zhang

 --
 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
 
 .




 --

 Kurtis Rader

 Caretaker of the exceptional canines Junior and Hank
 IMPORTANT NOTICE: The contents of this email and 

Re: [go-nuts] Re: compile time error vs runtime crash for same array

[Jan Mercl]

The linker knows nothing about heap. That's a runtime only thing.

On Fri, Nov 26, 2021, 05:00 arthurwil...@gmail.com <
arthurwilliammor...@gmail.com> wrote:

>
> On Saturday, November 13, 2021 at 12:48:41 PM UTC-6 seank...@gmail.com
> wrote:
>
>> global variables are stored in there data section of the compiled binary,
>> the linker imposes a 2GB size limit
>> the array in main can be allocated at runtime, and given enough memory,
>> it could succeed
>>
>>
> Why does the linker impose a 2GB limit on .bss data but not heap memory?
> Is there a limit on heap variables?
>
>
>>
>> On Saturday, November 13, 2021 at 5:46:29 PM UTC arthurwil...@gmail.com
>> wrote:
>>
>>> On a 64bit Mac, this code:
>>>
>>> package main
>>>
>>> var X [^uint(0)>>14]byte
>>> func main() {
>>> }
>>>
>>> produces a compile time error:
>>> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>>>
>>> But this compiles and crashes at runtime.
>>>
>>> package main
>>>
>>> func main() {
>>> var X [^uint(0) >> 14]byte
>>> _ = X
>>> }
>>>
>>> runtime: out of memory: cannot allocate 1125899906842624-byte block
>>> (3997696 in use)
>>> fatal error: out of memory
>>>
>>> goroutine 1 [running]:
>>> runtime.throw({0x1061335, 0x11})
>>> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658
>>> sp=0xc42628 pc=0x102b031
>>> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
>>> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8
>>> sp=0xc42658 pc=0x101086e
>>> runtime.mallocgc(0x3, 0x1059300, 0x1)
>>> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738
>>> sp=0xc426b8 pc=0x100a645
>>> runtime.newobject(0x1058a00)
>>> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760
>>> sp=0xc42738 pc=0x100aa87
>>> main.main()
>>> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780
>>> sp=0xc42760 pc=0x1054c65
>>> runtime.main()
>>> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0
>>> sp=0xc42780 pc=0x102d6c7
>>> runtime.goexit()
>>> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8
>>> sp=0xc427e0 pc=0x1051fa1
>>>
>>>
>>> Why does the 2nd program succeed compilation of the same array that
>>> failed compilation in the 1st program?
>>>
>>> It was known ahead of time that the allocation would fail so I think the
>>> 2nd program should have failed to compile too.
>>>
>>>
>>>
>>>
>>> --
> 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/5841fddd-8bf6-4e4e-b27c-7e74c8917516n%40googlegroups.com
> 
> .
>

-- 
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/CAA40n-XomDGsRNTAQW%3DhPihE_F%3DCYojbGhtS8B7M-E9nB5RVhg%40mail.gmail.com.

[go-nuts] Do pointer receiver methods need to be checked for nil?

[shinya sakae]

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+unsubscr...@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.

[go-nuts] Re: compile time error vs runtime crash for same array

[arthurwil...@gmail.com]

On Saturday, November 13, 2021 at 12:48:41 PM UTC-6 seank...@gmail.com 
wrote:

> global variables are stored in there data section of the compiled binary, 
> the linker imposes a 2GB size limit
> the array in main can be allocated at runtime, and given enough memory, it 
> could succeed
>
>
Why does the linker impose a 2GB limit on .bss data but not heap memory? Is 
there a limit on heap variables?  
 

>
> On Saturday, November 13, 2021 at 5:46:29 PM UTC arthurwil...@gmail.com 
> wrote:
>
>> On a 64bit Mac, this code:
>>
>> package main
>>
>> var X [^uint(0)>>14]byte
>> func main() {
>> }
>>
>> produces a compile time error:
>> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>>
>> But this compiles and crashes at runtime. 
>>
>> package main
>>
>> func main() {
>> var X [^uint(0) >> 14]byte
>> _ = X
>> }
>>
>> runtime: out of memory: cannot allocate 1125899906842624-byte block 
>> (3997696 in use)
>> fatal error: out of memory
>>
>> goroutine 1 [running]:
>> runtime.throw({0x1061335, 0x11})
>> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658 
>> sp=0xc42628 pc=0x102b031
>> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
>> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8 
>> sp=0xc42658 pc=0x101086e
>> runtime.mallocgc(0x3, 0x1059300, 0x1)
>> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738 
>> sp=0xc426b8 pc=0x100a645
>> runtime.newobject(0x1058a00)
>> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760 
>> sp=0xc42738 pc=0x100aa87
>> main.main()
>> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780 
>> sp=0xc42760 pc=0x1054c65
>> runtime.main()
>> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0 
>> sp=0xc42780 pc=0x102d6c7
>> runtime.goexit()
>> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8 
>> sp=0xc427e0 pc=0x1051fa1
>>
>>
>> Why does the 2nd program succeed compilation of the same array that 
>> failed compilation in the 1st program? 
>>
>> It was known ahead of time that the allocation would fail so I think the 
>> 2nd program should have failed to compile too.
>>
>>
>>
>>
>>

-- 
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/5841fddd-8bf6-4e4e-b27c-7e74c8917516n%40googlegroups.com.

Re: [go-nuts] some incorrect code in blog.

[David Karr]

I meant, did you test it with a bad path, and with the defer before the
error check?  I believe you implied that this didn't result in a failure.
It would have happened on exit from the method, if anything.

On Thu, Nov 25, 2021 at 12:49 PM Roland Müller  wrote:

> Yes. Actually I only tested with a non-existing file.
>
> But if you mean that case were also the directory is missing: behavior is
> still the same.
>
> BR,
> Roland
>
> func main() {
> f, err := os.Open("/tmp/dat_is_net_do/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
>   fmt.Println("NO FILE")
>   //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
>
> Am Do., 25. Nov. 2021 um 21:43 Uhr schrieb David Karr <
> davidmichaelk...@gmail.com>:
>
>> And did you test that with a file path that would fail?
>>
>> On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:
>>
>>> Hello,
>>>
>>> actually trying this with os.Open() the program behaves the same
>>> regardless whether the defer is before or after the error handling, Thus,
>>> no panic :-)
>>>
>>> Isn't anything declared with defer always running after the user code in
>>> the given func ends? I am too tired now to look this up.
>>>
>>> BR,
>>>
>>> Roland
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "os"
>>> )
>>>
>>> func main() {
>>> f, err := os.Open("/tmp/dat")
>>> //defer f.Close()
>>> fmt.Printf("%v\n", f)
>>> if err != nil {
>>>   fmt.Println("NO FILE")
>>>   //return
>>>}
>>>defer f.Close()
>>>fmt.Println("END")
>>> }
>>>
>>> Output:
>>> 
>>> NO FILE
>>> END
>>>
>>>
>>> On 11/25/21 10:19, Fannie Zhang wrote:
>>>
>>> OK, I see. Thank you.
>>>
>>>
>>>
>>> *From:* Kurtis Rader  
>>> *Sent:* Thursday, November 25, 2021 10:26 AM
>>> *To:* Fannie Zhang  
>>> *Cc:* golang-nuts 
>>> 
>>> *Subject:* Re: [go-nuts] some incorrect code in blog.
>>>
>>>
>>>
>>> Notice the date of that blog article: 2010-08-04. It's more than eleven
>>> years old. Blog articles are not updated as the language changes. However,
>>> in this case the example in that article is correct. If `os.Open()` returns
>>> an error then the `src` return value is invalid.
>>>
>>>
>>>
>>> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang 
>>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> There is some incorrect code in
>>> https://go.dev/blog/defer-panic-and-recover blog.
>>>
>>>
>>>
>>> The original code is
>>>
>>> *func CopyFile() {*
>>>
>>> *   ...*
>>>
>>> *   if err != nil {*
>>>
>>> *  return*
>>>
>>> *   }*
>>>
>>> *   defer src.Close()*
>>>
>>> *   ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I think the correct code should be
>>>
>>> *func CopyFile() {*
>>>
>>> *   ...*
>>>
>>> *   defer src.Close()*
>>>
>>> *   if err != nil {*
>>>
>>> *  return*
>>>
>>> *   }*
>>>
>>> *   ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I do not know how to modify the go blog, can anyone help? Thank you.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Fannie Zhang
>>>
>>> --
>>> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
>>> 
>>> .
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Kurtis Rader
>>>
>>> Caretaker of the exceptional canines Junior and Hank
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you. --
>>> 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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.com
>>> 
>>> .
>>>
>>> --
>>> 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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.com
>>> 

Re: [go-nuts] some incorrect code in blog.

[Roland Müller]

Yes. Actually I only tested with a non-existing file.

But if you mean that case were also the directory is missing: behavior is
still the same.

BR,
Roland

func main() {
f, err := os.Open("/tmp/dat_is_net_do/dat")
//defer f.Close()
fmt.Printf("%v\n", f)
if err != nil {
  fmt.Println("NO FILE")
  //return
   }
   defer f.Close()
   fmt.Println("END")
}


Am Do., 25. Nov. 2021 um 21:43 Uhr schrieb David Karr <
davidmichaelk...@gmail.com>:

> And did you test that with a file path that would fail?
>
> On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:
>
>> Hello,
>>
>> actually trying this with os.Open() the program behaves the same
>> regardless whether the defer is before or after the error handling, Thus,
>> no panic :-)
>>
>> Isn't anything declared with defer always running after the user code in
>> the given func ends? I am too tired now to look this up.
>>
>> BR,
>>
>> Roland
>>
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> )
>>
>> func main() {
>> f, err := os.Open("/tmp/dat")
>> //defer f.Close()
>> fmt.Printf("%v\n", f)
>> if err != nil {
>>   fmt.Println("NO FILE")
>>   //return
>>}
>>defer f.Close()
>>fmt.Println("END")
>> }
>>
>> Output:
>> 
>> NO FILE
>> END
>>
>>
>> On 11/25/21 10:19, Fannie Zhang wrote:
>>
>> OK, I see. Thank you.
>>
>>
>>
>> *From:* Kurtis Rader  
>> *Sent:* Thursday, November 25, 2021 10:26 AM
>> *To:* Fannie Zhang  
>> *Cc:* golang-nuts 
>> 
>> *Subject:* Re: [go-nuts] some incorrect code in blog.
>>
>>
>>
>> Notice the date of that blog article: 2010-08-04. It's more than eleven
>> years old. Blog articles are not updated as the language changes. However,
>> in this case the example in that article is correct. If `os.Open()` returns
>> an error then the `src` return value is invalid.
>>
>>
>>
>> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang 
>> wrote:
>>
>> Hi all,
>>
>>
>>
>> There is some incorrect code in
>> https://go.dev/blog/defer-panic-and-recover blog.
>>
>>
>>
>> The original code is
>>
>> *func CopyFile() {*
>>
>> *   ...*
>>
>> *   if err != nil {*
>>
>> *  return*
>>
>> *   }*
>>
>> *   defer src.Close()*
>>
>> *   ...*
>>
>> *}*
>>
>>
>>
>> I think the correct code should be
>>
>> *func CopyFile() {*
>>
>> *   ...*
>>
>> *   defer src.Close()*
>>
>> *   if err != nil {*
>>
>> *  return*
>>
>> *   }*
>>
>> *   ...*
>>
>> *}*
>>
>>
>>
>> I do not know how to modify the go blog, can anyone help? Thank you.
>>
>>
>>
>> Best regards,
>>
>> Fannie Zhang
>>
>> --
>> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
>> 
>> .
>>
>>
>>
>>
>> --
>>
>> Kurtis Rader
>>
>> Caretaker of the exceptional canines Junior and Hank
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you. --
>> 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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.com
>> 
>> .
>>
>> --
>> 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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.com
>> 
>> .
>>
>

-- 
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/CA%2B8p0G33uSM-sLxOW5vhXthCo%2Bt%2Bm3o1J%2BEpKo8QeGrb6sVcWQ%40mail.gmail.com.

Re: [go-nuts] some incorrect code in blog.

[David Karr]

And did you test that with a file path that would fail?

On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:

> Hello,
>
> actually trying this with os.Open() the program behaves the same
> regardless whether the defer is before or after the error handling, Thus,
> no panic :-)
>
> Isn't anything declared with defer always running after the user code in
> the given func ends? I am too tired now to look this up.
>
> BR,
>
> Roland
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> func main() {
> f, err := os.Open("/tmp/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
>   fmt.Println("NO FILE")
>   //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
> Output:
> 
> NO FILE
> END
>
>
> On 11/25/21 10:19, Fannie Zhang wrote:
>
> OK, I see. Thank you.
>
>
>
> *From:* Kurtis Rader  
> *Sent:* Thursday, November 25, 2021 10:26 AM
> *To:* Fannie Zhang  
> *Cc:* golang-nuts 
> 
> *Subject:* Re: [go-nuts] some incorrect code in blog.
>
>
>
> Notice the date of that blog article: 2010-08-04. It's more than eleven
> years old. Blog articles are not updated as the language changes. However,
> in this case the example in that article is correct. If `os.Open()` returns
> an error then the `src` return value is invalid.
>
>
>
> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang  wrote:
>
> Hi all,
>
>
>
> There is some incorrect code in
> https://go.dev/blog/defer-panic-and-recover blog.
>
>
>
> The original code is
>
> *func CopyFile() {*
>
> *   ...*
>
> *   if err != nil {*
>
> *  return*
>
> *   }*
>
> *   defer src.Close()*
>
> *   ...*
>
> *}*
>
>
>
> I think the correct code should be
>
> *func CopyFile() {*
>
> *   ...*
>
> *   defer src.Close()*
>
> *   if err != nil {*
>
> *  return*
>
> *   }*
>
> *   ...*
>
> *}*
>
>
>
> I do not know how to modify the go blog, can anyone help? Thank you.
>
>
>
> Best regards,
>
> Fannie Zhang
>
> --
> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
> 
> .
>
>
>
>
> --
>
> Kurtis Rader
>
> Caretaker of the exceptional canines Junior and Hank
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you. --
> 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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.com
> 
> .
>
> --
> 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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.com
> 
> .
>

-- 
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/CAA5t8Vq9m6rrR3GRcUqq-iKZc%3DX0okVuC6%2BPbH3n0zJx-SMZ7w%40mail.gmail.com.

Re: [go-nuts] some incorrect code in blog.

[Roland Müller]

Hello,

actually trying this with os.Open() the program behaves the same 
regardless whether the defer is before or after the error handling, 
Thus, no panic :-)


Isn't anything declared with defer always running after the user code in 
the given func ends? I am too tired now to look this up.


BR,

Roland

package main

import (
    "fmt"
    "os"
)

func main() {
    f, err := os.Open("/tmp/dat")
    //defer f.Close()
    fmt.Printf("%v\n", f)
    if err != nil {
  fmt.Println("NO FILE")
  //return
   }
   defer f.Close()
   fmt.Println("END")
}

Output:


NO FILE
END


On 11/25/21 10:19, Fannie Zhang wrote:


OK, I see. Thank you.

*From:* Kurtis Rader 
*Sent:* Thursday, November 25, 2021 10:26 AM
*To:* Fannie Zhang 
*Cc:* golang-nuts 
*Subject:* Re: [go-nuts] some incorrect code in blog.

Notice the date of that blog article: 2010-08-04. It's more than 
eleven years old. Blog articles are not updated as the language 
changes. However, in this case the example in that article is correct. 
If `os.Open()` returns an error then the `src` return value is invalid.


On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang  wrote:

Hi all,

There is some incorrect code in
https://go.dev/blog/defer-panic-and-recover blog.

The original code is

/func CopyFile() {/

/   .../

/   if err != nil {/

/      return/

/   }/

/   defer src.Close()/

/   .../

/}/

I think the correct code should be

/func CopyFile() {/

/   .../

/   defer src.Close()/

/   if err != nil {/

/      return/

/   }/

/   .../

/}/

I do not know how to modify the go blog, can anyone help? Thank you.

Best regards,

Fannie Zhang

-- 
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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com

.


--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you. --
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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.com 
.


--
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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.com.

Re: [go-nuts] Re: Tour of Go seems to be broken.

['Carla Pfaff' via golang-nuts]

On Thursday, 25 November 2021 at 18:43:44 UTC+1 bmar...@gmail.com wrote:

> I often give some training in my company about Go and I recommend the Tour 
> of Go as introducing but since September, french Tour of Go returns a http 
> 500 error (cf. my previous message 
> https://groups.google.com/g/golang-nuts/c/o8pBT6_z9OU/m/0q4Hn2JLAgAJ ) 
> and it seems to be still the case currently (page 
> https://go.dev/tour/welcome/2 --> select french --> 
> https://go-tour-fr.appspot.com/ = broken !)


The translated tours aren't maintained by the Go team. This one is 
https://github.com/dupoxy/go-tour-fr/issues/42 
The Go team can only remove unmaintained translations.

-- 
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/2acdce84-51c4-4e5e-847f-28c522f524c4n%40googlegroups.com.

Re: [go-nuts] Re: Tour of Go seems to be broken.

[bmar...@gmail.com]

I often give some training in my company about Go and I recommend the Tour 
of Go as introducing but since September, french Tour of Go returns a http 
500 error (cf. my previous 
message https://groups.google.com/g/golang-nuts/c/o8pBT6_z9OU/m/0q4Hn2JLAgAJ 
) and it seems to be still the case currently 
(page https://go.dev/tour/welcome/2 --> select french 
--> https://go-tour-fr.appspot.com/ = broken !)

Le mardi 23 novembre 2021 à 23:02:57 UTC+1, Ian Lance Taylor a écrit :

> On Mon, Nov 22, 2021 at 11:58 PM Brian Candler  wrote:
> >
> > It's working for me now. Either it was a temporary glitch, or there's 
> some problem with your browser that needs investigating (open your 
> developer console and see what happens when you click the Run button).
>
> After you reported the problem we fixed it with
> https://golang.org/cl/366376. I didn't follow up here because it was
> late in my timezone. Thanks for reporting the problem!
>
> 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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1888372f-dace-461d-acf9-fec675a5a35en%40googlegroups.com.

Re: [go-nuts] Re: New site go.dev is awful

[Ben Hoyt]

Thanks for that, Axel. Good to know they're aware of it and working on a
solution (of sorts).

On Thu, Nov 25, 2021 at 8:57 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> https://github.com/golang/go/issues/49765
> https://go-review.googlesource.com/c/website/+/366976/
>
>

-- 
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/CAL9jXCHKBfZtm1bgMYbUvVjh7FMmc36M5OobvWgjkTrkNDZVzw%40mail.gmail.com.

RE: [go-nuts] some incorrect code in blog.

[Fannie Zhang]

OK, I see. Thank you.

From: Kurtis Rader 
Sent: Thursday, November 25, 2021 10:26 AM
To: Fannie Zhang 
Cc: golang-nuts 
Subject: Re: [go-nuts] some incorrect code in blog.

Notice the date of that blog article: 2010-08-04. It's more than eleven years 
old. Blog articles are not updated as the language changes. However, in this 
case the example in that article is correct. If `os.Open()` returns an error 
then the `src` return value is invalid.

On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang 
mailto:fannie.zh...@arm.com>> wrote:
Hi all,

There is some incorrect code in https://go.dev/blog/defer-panic-and-recover 
blog.

The original code is
func CopyFile() {
   ...
   if err != nil {
  return
   }
   defer src.Close()
   ...
}

I think the correct code should be
func CopyFile() {
   ...
   defer src.Close()
   if err != nil {
  return
   }
   ...
}

I do not know how to modify the go blog, can anyone help? Thank you.

Best regards,
Fannie Zhang
--
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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com.


--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-- 
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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.com.