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 o
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 *Even
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 bu
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 o
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-
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 d
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
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.P
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 dec
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.
B
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/g
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 curre
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/
>
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 lang
14 matches
Mail list logo
