5 ms·
Why do we keep upvoting these short repetitive rants about Go? There are a half a different posts with this exact same complaint. There are another dozen thread
by drivebyacct2 14y ago
Why do we keep upvoting these short repetitive rants about Go? There are a half a different posts with this exact same complaint. There are another dozen threads about it on the mailing list with plenty of discussion and it comes up in almost every single comment thread here.
Yes, the error handling is explicit. If this is a bother panic/defer+recover is there if you want to use it.
The case here is completely contrived; a red-herring. It's not like it's ever typical to do m, err := io.Read... and not use the `m` (if you were, you'd already be writing _, err anyway). Assuming that you write a block of code and then compile it and not write all of your code line-by-line and compile it... and then I guess try to artificially fix the compiler message instead of writing the code to utilize m first?
edit: My only point is that this isn't even an issue that arises when normally writing code; the scenario in the blog isn't one that occurs when one sits down, writes a function and then compiles it. Sorry to whoever I upset.
- _ak 14y agoYou are totally right: in the last 2+ years I've programmed in Go, this has never been an issue. OP's example seems very contrived.
- randallsquared 14y ago> The case here is completely contrived; a red-herring. It's not like it's ever typical to do m, err := io.Read... and not use the `m` (if you were, you'd already be writing _, err anyway). I've been doing some Go recently, and I ran into this exact problem (except the rhs was something else). Ignoring the output of a not-directly-related function while debugging is quite common, in my experience. Like some others here, it didn't rise for me to the level of ranting about it, but it's interesting to see that it's not just me, so I'm glad it did for someone. :)