Comment by zwnow

Comment by zwnow 2 days ago

> Wait, what? Why is err reused for foo2()? Is there’s something subtle I’m not seeing? Even if we change that to :=, we’re left to wonder why err is in scope for (potentially) the rest of the function. Why? Is it read later?

First time its assigned nil, second time its overwritten in case there's an error in the 2nd function. I dont see the authors issue? Its very explicit.

thomashabets2 2 days ago

Author here: I'm not talking about the value. I'm talking about the lifetime of the variable.

After checking for nil, there's no reason `err` should still be in scope. That's why it's recommended to write `if err := foo(); err != nil`, because after that, one cannot even accidentally refer to `err`.

I'm giving examples where Go syntactically does not allow you to limit the lifetime of the variable. The variable, not its value.

You are describing what happens. I have no problem with what happens, but with the language.

Reply View 2 replies

zwnow 2 days ago

Why does the lifetime even matter?

Reply View | 1 reply
- thomashabets2 2 days ago
  
  I gave an example in the post, but to spell it out: Because a typo variable is not caught, e.g. as an unused variable.
  The example from the blog post would fail, because `return err` referred to an `err` that was no longer in scope. It would syntactically prevent accidentally writing `foo99()` instead of `err := foo99()`.
  
  Reply View | 0 replies

lowmagnet 2 days ago

I'll have to read the rest later but this was an unforced error on the author's part. There is nothing unclear about that block of code. If err isn't but, it was set, and we're no longer in the function. If it's not, why waste an interface handle?

Reply View 0 replies