You’re describing some other language that forces you to deal with errors, like Haskell or Rust.
A bare
io.WriteString(w, “ok”)
a, b := someFunc()
fmt.Println(b)
It's not a big deal.
A quick work around for that example would be to a line: `b = b`.
Go vet complains but it builds and runs.
Not true at all. The easiest example is:
func main() {
fmt.Println("")
}
There are actually better ways. Rust and Haskell not only fix this problem without breaking function composition... they make it so that the compiler is able to catch missing error handling logic.
The golang way of doing this is not the ideal way, but it does fix your issue with python.
Usually the answer is to wait for an actual exception and if it's not something you could actually anticipate, then write a tiny try block that just handles the exception. The whole point being that I want it to fail if there is an unknown exception. Which in Go, you wont fail at runtime if you are just printing errors as a habit( I think, I have not done much with go).
That said, a lot of times it makes sense to return errors, and perhaps there in lies the difference between an exception and an error.
Yeah, that is a problem. At least they had to manually type it out and (maybe) think about how to handle the error during that time. To streamline this is to further exacerbate the issue. They will do a try/catch try/defer `log.Println`.
With Python try/catch allows for ultimate laziness. It allows for 1,000 line try/catch blocks that can hide/capture errors that bubble up from anywhere. Of course this is bad development but it's possible. Currently with Go it is impossible to forget about error handling. You have to consciously make a choice on what to do with it. Even if that choice is to log/print it out.