5 ms·

> "Defer" is blind. With "defer", nobody ever finds out that the close failed to write the end of the file. This is simply false and a misconception held by pe

by donatj 10y ago

> "Defer" is blind. With "defer", nobody ever finds out that the close failed to write the end of the file. This is simply false and a misconception held by people who haven't spent a lot of time with the language. You not only can, but absolutely SHOULD handle errors in defers. Using named return parameters on your method, your error return is still in scope and can be set. This is how you properly handle errors on defers. See: https://play.golang.org/p/kPx3ipkMhF https://play.golang.org/p/kPx3ipkMhF

pcwalton 10y ago
> This is simply false and a misconception held by people who haven't spent a lot of time with the language. If you've spent a lot of time with the language, then you've surely noticed that people rarely do this (because it's extremely verbose). The language encourages ignoring errors in defer. (Contrary to the parent post, I'm not sure this is a real problem, however.)
Animats 10y ago
That is so cool. And confusing. And likely to lead to errors. Error handling should not require l33t features. (This is my big argument with both Go and Rust. The stuff they use to get around not having exceptions is worse than exceptions.)
- kibwen 10y ago
  As though exceptions themselves are somehow not a "l33t feature". :P
- donatj 10y ago
  I wouldn't really call "return values" a "l33t feature". Exceptions are absolutely a "l33t feature". They break whatever is currently happening. They are an uncontrolled return working its way up your structure. While you're attempting to recover from that Exception I gracefully catch my error and can even use the multiple return values that came back successfully from my function, despite there being an error.
themihai 10y ago
That's right but you are not returning the error. Here is the corrected snippet https://play.golang.org/p/A3YRSTg-7K https://play.golang.org/p/A3YRSTg-7K Edit: your example works too, though I find it weird...

by donatj 10y ago

pcwalton 10y ago

> This is simply false and a misconception held by people who haven't spent a lot of time with the language. If you've spent a lot of time with the language, then you've surely noticed that people rarely do this (because it's extremely verbose). The language encourages ignoring errors in defer. (Contrary to the parent post, I'm not sure this is a real problem, however.)

Animats 10y ago

That is so cool. And confusing. And likely to lead to errors. Error handling should not require l33t features. (This is my big argument with both Go and Rust. The stuff they use to get around not having exceptions is worse than exceptions.)

kibwen 10y ago
As though exceptions themselves are somehow not a "l33t feature". :P
donatj 10y ago
I wouldn't really call "return values" a "l33t feature". Exceptions are absolutely a "l33t feature". They break whatever is currently happening. They are an uncontrolled return working its way up your structure. While you're attempting to recover from that Exception I gracefully catch my error and can even use the multiple return values that came back successfully from my function, despite there being an error.

themihai 10y ago

That's right but you are not returning the error. Here is the corrected snippet https://play.golang.org/p/A3YRSTg-7K https://play.golang.org/p/A3YRSTg-7K Edit: your example works too, though I find it weird...