Re:Exploring Error Handling Patterns in Go
by Groxx on Saturday August 25, 2018 @02:41PM
(#17841946)
Is that any worse than the ambiguity in e.g. code like this?
func thing(arg) {
otherThing(arg) // does this return an error you're ignoring?
}
It even has a similar problem, where void returns -> err returns on code changes are not visibly discoverable (similar to a newly-throwing func).
Granted, you could turn this into a compiler error. But it's not currently.
---
Anyway. Given that so many not-prevented-by-the-typesystem operations panic, I don't think it's reasonable to assume that any func call will not panic, especially not in the future since they may change. So you already have to program with `defer` to maintain your invariants, which is exactly the same as with exceptions, except you now have to deal with both possibilities for nearly every func.
Granted, you could turn this into a compiler error. But it's not currently.
---
Anyway. Given that so many not-prevented-by-the-typesystem operations panic, I don't think it's reasonable to assume that any func call will not panic, especially not in the future since they may change. So you already have to program with `defer` to maintain your invariants, which is exactly the same as with exceptions, except you now have to deal with both possibilities for nearly every func.