4 ms·
Wait, what? The OP said that they like Go’s error handling because it forces them to think about errors and make their code more robust. You’re saying you lik
by comex 7y ago
Wait, what? The OP said that they like Go’s error handling because it forces them to think about errors and make their code more robust. You’re saying you like Go as a “quick and dirty git-er-done tool”. Those are opposite viewpoints! For your use case, it seems like something like try() being added to Go would be a benefit, since it would make it easier to write “quick and dirty” code that still provides at least basic error handling.
- apta 7y agoI see many golang users just parrot what golang authors say, without having any evidence about those claims. Things like "golang is designed for development in the large", or "golang forces you to think about errors" or that the way it handles errors is robust, all claims that have nothing to support them (on the contrary, reality is the opposite of those claims).
- bmurphy1976 7y agoI mostly agree with the op. I was replying to pcwalton's comment, or more specifically those who would solve every problem with a monadic straight jacket. I don't agree that that is always the best way to handle errors. There are tradeoffs involved that are hard to define but really do make a difference. I think Go finds a sweet spot thay has been ignored by the academic community. Hence my labeling of Go's error handling as conceptually imperfect.