[error] A more complex error interface

[at15]

The default error interface is simple Error() string, however, it is too general and makes error handling non trivial, user have to rely on inspect string/type assertion/compare with global variable. Some use cases

• error code, might just add ErrorCode to the general interface and give code to common std library errors
• [error] Allow find cause and inspect error without checking key words in error message #66 error class/kind, i.e. network, encoding etc.
• reason, this is already of solved by using Wrap
• [error] Human readable suggestions for possible solutions #73 solution, some errors are simple but common, might just write the solution there, just like when you do brew install it will suggest you run certain command when there are certain errors.
• error tracking system like sentry, I remember I have a survey/issue for those stuff somewhere
• a generic http retry client, not all error are retryable, i.e. a 500 could also contains a valid response for application specific error, it would be good to have a ShouldRetry

Related

• [error] Tracker go.ice#12
• [error] A more complex error interface #76 (comment) go2 error handling proposal
• https:/dgraph-io/dgraph/blob/master/x/error.go they have a check(_ interface{}, err error)
• https:/gravitational/trace/blob/master/errors.go defines some common error interface, it also wrap, unwrap, user message etc.