> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them. Like:
I dislike it because it does the opposite, it makes it too easy to accidentally continue execution when there is an error:
doThing(); // Error
doOtherThing();
Which isn't possible with Exceptions.
The only thing that would signal that error handling is missing is the absence of boilerplate to handle it, which is an ugly UX for a language to rely on esp given there's no indication from scanning code that all methods that return errors are handled.
The nice thing about a statically typed language having standard golint and gofmt is that code is generally self documenting. So I wouldn't ever type that function call without seeing the function definition (in my editor or wherever else I found the API reference).
But I agree, the fact that Go allows this is bad, imo. It would be better if you had to explicitly suppress errors, even with something like this "_ = doThing()" just to make it harder to miss.
I don't know go, so I'm confused here. If nothing failed, the error is just made silent? The program will move to doOtherThing, as if nothing failed, and everything will move forward?
The error was just ignored. if doThing() had some side effect that doOtherThing() depended on then you will never know why doOtherThing() isn't working the way you expect it to be.
Ya that seems pretty unsafe to me. I'm not sure then why others suggest the Go error handling makes things safer. Silent failures have always been some of the most impacting issues in the systems I've maintained. They cause slow corruption and they take a long time to be found, at that point, the damage is done and hard to revert.
I dislike it because it does the opposite, it makes it too easy to accidentally continue execution when there is an error:
Which isn't possible with Exceptions.The only thing that would signal that error handling is missing is the absence of boilerplate to handle it, which is an ugly UX for a language to rely on esp given there's no indication from scanning code that all methods that return errors are handled.