4 ms·
> Currently with Go it is impossible to forget about error handling. You’re describing some other language that forces you to deal with errors, like Haskell or
by msbarnett 7y ago
> Currently with Go it is impossible to forget about error handling.
You’re describing some other language that forces you to deal with errors, like Haskell or Rust.
A bare
io.WriteString(w, “ok”)
will happily compile despite returning a completely unhandled error.
- xmprt 7y agoMeanwhile code like a, b := someFunc() fmt.Println(b) throws a compiler error like it's the end of the world if you define a variable that isn't used.
- pstuart 7y agoIf you can type "a, b :=", you can type "_, b :=". It's not a big deal.
- saghm 7y agoWhen I wrote Go at work, this would mostly be annoying when interactively writing and running code; if I want to comment out the only line below that uses `a` and run it again, now I have to go back and change the declaration also. Once I want to to run that line again, I can't just uncomment it; I have to go back and declare it again. I would have to do stuff like this fairly often when trying to debug failed tests, so despite the fact that I'd never want to _commit_ code with an unused variable, I certainly would like to be able to _run_ it when debugging. I feel like a warning is definitely better than a hard error here; it's pretty easy in most languages with warnings to set up CI to reject unused variables, which ensures that your code in production won't have any unused variables.
- pstuart 7y agoUnderstood. I think the problem is that once options like that are given they become abused and eventually institutionalized. A quick work around for that example would be to a line: `b = b`. Go vet complains but it builds and runs.