Skip to content

[error] A more complex error interface #76

Open
@at15

Description

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions