3 ms·
> but I kinda like having errors as values this is the sort of silliness that is common in the Go world. as noted elsewhere, errors are values in lots of lang
by bananapub 3y ago
> but I kinda like having errors as values
this is the sort of silliness that is common in the Go world. as noted elsewhere, errors are values in lots of languages - Rust, C, Scala, Haskell, etc etc, but Go explicitly has no way to handle them nicely, no specific syntax and no fancy type system stuff like sum types.
it is my very strong belief that this will eventually be fixed in Go and when it does, almost all the people currently saying "I like errors being values [and it's fine that Go makes it very annoying]" will quickly prefer having some actual language help for these values.
- tail_exchange 3y agoGo actually has something akin to Sum types for errors, called wrapping. For example: var innerErr = errors.New("inner error") func innerFunc() error { return innerErr } func outerFunc() error { err := innerFunc() return fmt.Errorf("outer err: %w", err) } func main() { err := outerFunc() fmt.Println(errors.Is(err, innerErr)) // true } I don't think the Go community disagrees that it would be nice to make error handling a bit easier, because that was the top issue raised in the recent developer survey. The problem is that every proposal made so far either did not actually make error handling that much better, by looking at the feedback they received.