4 ms·
The problem is that you don't need to mutate every error at every frame in the stack. I've seen codebases which religiously follow this rule, and most of the `f
by samhw 5y ago
The problem is that you don't need to mutate every error at every frame in the stack. I've seen codebases which religiously follow this rule, and most of the `fmt.Errorf` calls don't have much more to say than "error in f(): %s".
Languages that implement error handling well do not communicate error states in the form of massive strings like `call to f() failed: g() returned an error with parameter '123': error in h(), with argument x = 'interface{}{}': connection failed`.
- gruez 5y ago>Languages that implement error handling well do not communicate error states in the form of massive strings like ... In other words, exceptions with a stack trace. It's funny how that pattern is being reimplemented because it's not available in go
- marcus_holmes 5y agoNot funny, kinda disastrous ;) The error interface's only member is `func Error() string`. If you want to do fancy things with errors rather than accumulate a massive string then there is absolutely nothing stopping you. As long as you include a `func Error() string` in there too then whatever you implement will be perfectly compatible with the std library and any other Go code that uses errors.
- Andys 5y agoNot available? But that's exactly what Go's panic/recover system does.