Skip to content

Instantly share code, notes, and snippets.

@andrewchambers
Last active August 28, 2018 23:07
Show Gist options
  • Select an option

  • Save andrewchambers/5cadb2b8b45271440f1a051bb1ccc9c6 to your computer and use it in GitHub Desktop.

Select an option

Save andrewchambers/5cadb2b8b45271440f1a051bb1ccc9c6 to your computer and use it in GitHub Desktop.

Revisions

  1. andrewchambers revised this gist Aug 28, 2018. 1 changed file with 5 additions and 4 deletions.
    9 changes: 5 additions & 4 deletions errors.md
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,8 @@
    My observation is that a root cause of an error is special, most values in the
    error chain are only used except to preserve line information. Users
    and debuggers usually only care about the first error and the last
    error in the chain. In the end I disliked pkg/errors naming conventions and
    My observation is that a root cause of an error is special,
    I usually only care about the first error and the last
    error in the chain except for logs.

    In the end I disliked pkg/errors naming conventions and
    wrote my own small package.

    A typical usage of my package in a server:
  2. andrewchambers revised this gist Aug 28, 2018. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions errors.md
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,8 @@
    In my own code, I use my own error package. My observation
    is that a root cause of an error is special, most values in the
    error chain are useless except to preserve line information. Users
    My observation is that a root cause of an error is special, most values in the
    error chain are only used except to preserve line information. Users
    and debuggers usually only care about the first error and the last
    error in the chain.
    error in the chain. In the end I disliked pkg/errors naming conventions and
    wrote my own small package.

    A typical usage of my package in a server:

  3. andrewchambers created this gist Aug 28, 2018.
    31 changes: 31 additions & 0 deletions errors.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,31 @@
    In my own code, I use my own error package. My observation
    is that a root cause of an error is special, most values in the
    error chain are useless except to preserve line information. Users
    and debuggers usually only care about the first error and the last
    error in the chain.

    A typical usage of my package in a server:

    ```
    err := errors.Wrapf(err, "Additional context: %s", s)
    ...
    if errors.RootCause(err) != sql.ErrNoRows {
    Log("an error happend", "trace", errors.Trace(err))
    }
    ```

    A typical usage in a cli application is:

    ```
    ...
    if err != nil {
    // err.Error() only cares about the top level error and the root cause
    fmt.Fprintf(os.Stderr, "%s\n", err.Error()) // 'Init failed' caused by 'File foo.cfg does not exist'
    os.Exit(1)
    }
    ```

    One big lack I found is knowing the possible values of RootCause... A Go guru
    like analysis may help. especially a way to check reality with what the
    doc comments say.