3 ms·
"What only matters is the unwrapping procedure and conversion to string because that is what is needed." This, in a nutshell, encapsulates what Go gets wrong a
by sidlls 4y ago
"What only matters is the unwrapping procedure and conversion to string because that is what is needed."
This, in a nutshell, encapsulates what Go gets wrong about error handling. The simplicity is great; the extreme simplicity at the expense of runtime efficiency and clarity is not. Errors are not just strings. They can (and should) encode information, and the language should support that efficiently. And the mechanisms Go includes to make it more ergonomic impose small penalties in performance that add up at scale. This "solution" doesn't help that (it makes it worse).
- nhooyr 4y agoThis blog post is inaccurate. The only information an error is required to implement is their string representation. You can add whatever you want on top, there are no further restrictions.
- sidlls 4y agoIt's true that you can add additional information via structs or even just `fmt.Errorf`, but I disagree that the blog post is inaccurate. Fundamentally Go's error handling is very much string-centered. All the extra encapsulation you add via structs implementing the `error` interface just make things worse, because of the poor design to check those types (`errors.As` is a monstrosity).
- lzap 4y agoI was trying to say that eventually, errors in Go distill to strings. Of course the type which represents errors can be anything, I thought it is obvious and it is also mentioned in the introduction section which you may have skipped.