Inspired by Rob Pike's recent blog post <https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html> and Dave Cheney's errors package <https://github.com/pkg/errors/>, I wrote down some methods that I think all errors should implement.
The key idea is that an error only needs to implement a particular method to buy in to a piece of functionality. The bits of functionality are orthogonal. (Cheney's package exemplifies this.) If errors implement the right methods, then consumers of errors will have an easier time classifying errors, taking action on them, and getting more information about them. I wrote some code <https://github.com/jba/errors> that includes an interface, a useful implementation, and some helper methods. But the essential point is to agree on method names and the overall approach: - For chaining errors, an error should implement ErrorSource() error. Many call this "Cause," but that implies a direction of causality that may not be accurate. (I prefix all the methods with "Error" to avoid collisions with existing methods, so retrofitting is painless.) - For additional information, an error should implement ErrorDetails() interface{}. The information can be a stack trace, for example. - Error types should be expressed with integer codes. To distinguish different sets of codes, use a unique string identifying the space of codes, like HTTP or gRPC. The method to implement is ErrorCode() (space string, code int). There's a natural reluctance to use numeric codes when you can use the type system to provide a richer experience. But the killer feature of integers is that every programming language has them, so it is easy to pass errors around a polyglot system. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
