4 ms·

> Whatever you do, always check your errors! Would probably help if you did not need an external linter to remind you. Alas, here as well Go is all hat.

Animats 3y ago
"All hat and no cattle", a Texas insult?
cratermoon 3y ago
> if you did not need an external linter to remind you That's true if the function doesn't return a value (other than the error) or if it does and the caller also ignores the return value. That is, given func F() error { ... } It's legal to call F() without checking the return. However in the case that the function returns a value and an error, like so func G() (int, error) { ... } then it's fine to just call G() and ignore anything returned, but i := G() will cause a compile error. It's possible to assign one or both values to the Blank Identifier, the underscore _, so ignoring the error, while possible, requires the code to reflect the intent, like so i, _ := G() but i, err := G() will fail to compile if either i or err are not used following the call. https://go.dev/play/p/Z8xNWiJHPV0 https://go.dev/play/p/Z8xNWiJHPV0 Maybe the compiler should require the error return to be assigned for F(), that's a bit of a quirk that's under discussion.
- masklinn 3y ago
  > That's true if the function doesn't return a value (other than the error) or if it does and the caller also ignores the return value. “Yes” would have done just fine, especially as this is not uncommon when it comes to IO. But then again who’d do IO in Go right? > will fail to compile if either i or err are not used following the call. a, err := G() if err != nil { panic(err) } i, err := G() i, err = G() err = F() fmt.Println("Got", a, i) > Maybe the compiler should require the error return to be assigned for F(), that's a bit of a quirk that's under discussion. It’s not “a bit of a quirk”. The langage only checks for unused variables which is woefully insufficient and unfit for purpose, and has been since the langage was first released.
  - cratermoon 3y ago
    You seem nice.

Animats 3y ago

"All hat and no cattle", a Texas insult?

cratermoon 3y ago

> if you did not need an external linter to remind you That's true if the function doesn't return a value (other than the error) or if it does and the caller also ignores the return value. That is, given func F() error { ... } It's legal to call F() without checking the return. However in the case that the function returns a value and an error, like so func G() (int, error) { ... } then it's fine to just call G() and ignore anything returned, but i := G() will cause a compile error. It's possible to assign one or both values to the Blank Identifier, the underscore _, so ignoring the error, while possible, requires the code to reflect the intent, like so i, _ := G() but i, err := G() will fail to compile if either i or err are not used following the call. https://go.dev/play/p/Z8xNWiJHPV0 https://go.dev/play/p/Z8xNWiJHPV0 Maybe the compiler should require the error return to be assigned for F(), that's a bit of a quirk that's under discussion.

masklinn 3y ago
> That's true if the function doesn't return a value (other than the error) or if it does and the caller also ignores the return value. “Yes” would have done just fine, especially as this is not uncommon when it comes to IO. But then again who’d do IO in Go right? > will fail to compile if either i or err are not used following the call. a, err := G() if err != nil { panic(err) } i, err := G() i, err = G() err = F() fmt.Println("Got", a, i) > Maybe the compiler should require the error return to be assigned for F(), that's a bit of a quirk that's under discussion. It’s not “a bit of a quirk”. The langage only checks for unused variables which is woefully insufficient and unfit for purpose, and has been since the langage was first released.
- cratermoon 3y ago
  You seem nice.