4 ms·
Cool to see in terms of Go style how they handle errors -- https://github.com/upspin/upspin/blob/master/errors/errors.go https://github.com/upspin/upspin/blob/m
by spraak 10y ago
Cool to see in terms of Go style how they handle errors -- https://github.com/upspin/upspin/blob/master/errors/errors.go https://github.com/upspin/upspin/blob/master/errors/errors.g... It's a common pattern I've seen, but given that this comes from Rob Pike etc., glad to see that the pattern is considered a good one
Edit: I sound like a total fangirl :/
- zalmoxes 10y agoI'm excited to see what kind of discussion comes up around this codebase. It's worth noting /u/eneff's comment about the initial code though: https://twitter.com/enneff/status/834167073508978689 https://twitter.com/enneff/status/834167073508978689
- spraak 10y agoNice thanks for sharing that :)
- morecoffee 10y agoIt's such a good pattern, that other languages have even standardized it. Java's exceptions are basically the same thing: The stacktrace and the underlying exception come by default. Arguably, Go made a mistake here by not having featureful errors, since now each project has to reimplement them.
- mixedCase 10y agoThat's one take on it, but these error types are vastly more lightweight than exceptions when the code isn't hitting the happy path (and there's little difference when it isn't). Plus, when I write Java I have to constantly specify new Exception types. I don't see anything wrong with having to do it for Go when I really want more or less data depending on circumstance.