3 ms·
Go's errors have basically all the problems of exception handling in previous generation languages (and a few novel ones). This explains it (tl;dr nobody bothe
by voidnullnil 5y ago
Go's errors have basically all the problems of exception handling in previous generation languages (and a few novel ones).
This explains it (tl;dr nobody bothers to formally define what errors they return, and the blindly propagate such unspecified errors, and it leads to ambiguity and unintentional program behavior)
https://www.lainchan.org/%CE%BB/src/1612397614615.jpg https://www.lainchan.org/%CE%BB/src/1612397614615.jpg
https://www.lainchan.org/%CE%BB/src/1612397701473.jpg https://www.lainchan.org/%CE%BB/src/1612397701473.jpg
https://www.lainchan.org/%CE%BB/src/1612398029019.jpg https://www.lainchan.org/%CE%BB/src/1612398029019.jpg
- astrange 5y agoSwift considered this and still decided to have untyped error returns. The issues are: - wrapping every underlying error in your own error type is not helpful - but defining every underlying error in your own type confuses your implementation (and especially dependencies) with your interface - and most errors can't be handled in code anyway There are a few errors (mostly in file operations) that are individually handled as normal parts of life, but otherwise they really are just there to send back up to the user. It's more important to know where an error can happen than what it is.