3 ms·
There was just so much nonsense back in the day around Go's error handling and about how it was so much more straightforward than adding exceptions to the langu
by talideon 3y ago
There was just so much nonsense back in the day around Go's error handling and about how it was so much more straightforward than adding exceptions to the language.
In reality, the only reason why errors in Go work the way they do is that it kept the runtime simpler by offloading checking to the developer. The alternative would've been for Go to support sum types, which would've helped make error handling a lot saner, but that was dismissed because they overlapped a little with structurally-typed interfaces (Go's one really good idea). Oh, and the stupid hack that is 'iota'.
And then Go eventually ended up badly re-inventing most of what exceptions do with errors.Is(), errors.As(), and fmt.Errorf("%w", err).
It's such a hot mess.
- preseinger 3y agonope! go's error handling is actually good! it turns out that treating errors the same as normal values makes programs more reliable lots of people get salty about it, for sure
- talideon 3y agoThe _right_ way to treat them as normal values is by using sum types. So no, Go's error handling isn't at all good. 1.13 might've made them less execrable, but it didn't make it good.
- preseinger 3y agoyou know i looked into it and it turns out that there is no actual consensus on what "the _right_ way" to treat errors is! huh! how about that