eris provides a better way to handle, trace, and log errors in Go 🎆

Overview

eris Logo

GoDoc Build Coverage Status GoReport Discord Mentioned in Awesome Go Sourcegraph

Package eris provides a better way to handle, trace, and log errors in Go.

go get github.com/rotisserie/eris

Why you'll want to switch to eris

Named after the Greek goddess of strife and discord, this package is designed to give you more control over error handling via error wrapping, stack tracing, and output formatting. eris was inspired by a simple question: what if you could fix a bug without wasting time replicating the issue or digging through the code?

eris is intended to help developers diagnose issues faster. The example that generated the output below simulates a realistic error handling scenario and demonstrates how to wrap and log errors with minimal effort. This specific error occurred because a user tried to access a file that can't be located, and the output shows a clear path from the top of the call stack to the source.

{
  "error":{
    "root":{
      "message":"error internal server",
      "stack":[
        "main.main:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:143",
        "main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:85",
        "main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:82",
        "main.GetRelPath:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:61"
      ]
    },
    "wrap":[
      {
        "message":"failed to get relative path for resource 'res2'",
        "stack":"main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:85"
      },
      {
        "message":"Rel: can't make ./some/malformed/absolute/path/data.json relative to /Users/roti/",
        "stack":"main.GetRelPath:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:61"
      }
    ]
  },
  "level":"error",
  "method":"ProcessResource",
  "msg":"method completed with error",
  "time":"2020-01-16T11:20:01-05:00"
}

Many of the methods in this package will look familiar if you've used pkg/errors or xerrors, but eris employs some additional tricks during error wrapping and unwrapping that greatly improve the readability of the stack which should make debugging easier. This package also takes a unique approach to formatting errors that allows you to write custom formats that conform to your error or log aggregator of choice. You can find more information on the differences between eris and pkg/errors here.

Using eris

Creating errors

Creating errors is simple via eris.New.

var (
  // global error values can be useful when wrapping errors or inspecting error types
  ErrInternalServer = eris.New("error internal server")
)

func (req *Request) Validate() error {
  if req.ID == "" {
    // or return a new error at the source if you prefer
    return eris.New("error bad request")
  }
  return nil
}

Wrapping errors

eris.Wrap adds context to an error while preserving the original error.

relPath, err := GetRelPath("/Users/roti/", resource.AbsPath)
if err != nil {
  // wrap the error if you want to add more context
  return nil, eris.Wrapf(err, "failed to get relative path for resource '%v'", resource.ID)
}

Formatting and logging errors

eris.ToString and eris.ToJSON should be used to log errors with the default format (shown above). The JSON method returns a map[string]interface{} type for compatibility with Go's encoding/json package and many common JSON loggers (e.g. logrus).

// format the error to JSON with the default format and stack traces enabled
formattedJSON := eris.ToJSON(err, true)
fmt.Println(json.Marshal(formattedJSON)) // marshal to JSON and print
logger.WithField("error", formattedJSON).Error() // or ideally, pass it directly to a logger

// format the error to a string and print it
formattedStr := eris.ToString(err, true)
fmt.Println(formattedStr)

eris also enables control over the default format's separators and allows advanced users to write their own custom output format.

Interpreting eris stack traces

Errors created with this package contain stack traces that are managed automatically. They're currently mandatory when creating and wrapping errors but optional when printing or logging. By default, the stack trace and all wrapped layers follow the opposite order of Go's runtime package, which means that the original calling method is shown first and the root cause of the error is shown last.

{
  "root":{
    "message":"error bad request", // root cause
    "stack":[
      "main.main:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:143", // original calling method
      "main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:71",
      "main.(*Request).Validate:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:29", // location of Wrap call
      "main.(*Request).Validate:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:28" // location of the root
    ]
  },
  "wrap":[
    {
      "message":"received a request with no ID", // additional context
      "stack":"main.(*Request).Validate:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:29" // location of Wrap call
    }
  ]
}

Inverting the stack trace and error output

If you prefer some other order than the default, eris supports inverting both the stack trace and the entire error output. When both are inverted, the root error is shown first and the original calling method is shown last.

// create a default format with error and stack inversion options
format := eris.NewDefaultStringFormat(eris.FormatOptions{
  InvertOutput: true, // flag that inverts the error output (wrap errors shown first)
  WithTrace: true,    // flag that enables stack trace output
  InvertTrace: true,  // flag that inverts the stack trace output (top of call stack shown first)
})

// format the error to a string and print it
formattedStr := eris.ToCustomString(err, format)
fmt.Println(formattedStr)

// example output:
// error not found
//   main.GetResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:52
//   main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:76
//   main.main:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:143
// failed to get resource 'res1'
//   main.GetResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:52

Inspecting errors

The eris package provides a couple ways to inspect and compare error types. eris.Is returns true if a particular error appears anywhere in the error chain. Currently, it works simply by comparing error messages with each other. If an error contains a particular message (e.g. "error not found") anywhere in its chain, it's defined to be that error type.

ErrNotFound := eris.New("error not found")
_, err := db.Get(id)
// check if the resource was not found
if eris.Is(err, ErrNotFound) {
  // return the error with some useful context
  return eris.Wrapf(err, "error getting resource '%v'", id)
}

eris.As finds the first error in a chain that matches a given target. If there's a match, it sets the target to that error value and returns true.

var target *NotFoundError
_, err := db.Get(id)
// check if the error is a NotFoundError type
if errors.As(err, &target) {
    // err is a *NotFoundError and target is set to the error's value
    return target
}

eris.Cause unwraps an error until it reaches the cause, which is defined as the first (i.e. root) error in the chain.

ErrNotFound := eris.New("error not found")
_, err := db.Get(id)
// compare the cause to some sentinel value
if eris.Cause(err) == ErrNotFound {
  // return the error with some useful context
  return eris.Wrapf(err, "error getting resource '%v'", id)
}

Formatting with custom separators

For users who need more control over the error output, eris allows for some control over the separators between each piece of the output via the eris.Format type. If this isn't flexible enough for your needs, see the custom output format section below. To format errors with custom separators, you can define and pass a format object to eris.ToCustomString or eris.ToCustomJSON.

// format the error to a string with custom separators
formattedStr := eris.ToCustomString(err, Format{
  FormatOptions: eris.FormatOptions{
    WithTrace: true,   // flag that enables stack trace output
  },
  MsgStackSep: "\n",   // separator between error messages and stack frame data
  PreStackSep: "\t",   // separator at the beginning of each stack frame
  StackElemSep: " | ", // separator between elements of each stack frame
  ErrorSep: "\n",      // separator between each error in the chain
})
fmt.Println(formattedStr)

// example output:
// error reading file 'example.json'
//   main.readFile | .../example/main.go | 6
// unexpected EOF
//   main.main | .../example/main.go | 20
//   main.parseFile | .../example/main.go | 12
//   main.readFile | .../example/main.go | 6

Writing a custom output format

eris also allows advanced users to construct custom error strings or objects in case the default error doesn't fit their requirements. The UnpackedError object provides a convenient and developer friendly way to store and access existing error traces. The ErrRoot and ErrChain fields correspond to the root error and wrap error chain, respectively. If a root error wraps an external error, that error will be default formatted and assigned to the ErrExternal field. If any other error type is unpacked, it will appear in the ErrExternal field. You can access all of the information contained in an error via eris.Unpack.

// get the unpacked error object
uErr := eris.Unpack(err)
// send only the root error message to a logging server instead of the complete error trace
sentry.CaptureMessage(uErr.ErrRoot.Msg)

Sending error traces to Sentry

eris supports sending your error traces to Sentry using the Sentry Go client SDK. You can run the example that generated the following output on Sentry UI using the command go run examples/sentry/example.go -dsn=<DSN>.

*eris.wrapError: test: wrap 1: wrap 2: wrap 3
  File "main.go", line 19, in Example
    return eris.New("test")
  File "main.go", line 23, in WrapExample
    err := Example()
  File "main.go", line 25, in WrapExample
    return eris.Wrap(err, "wrap 1")
  File "main.go", line 31, in WrapSecondExample
    err := WrapExample()
  File "main.go", line 33, in WrapSecondExample
    return eris.Wrap(err, "wrap 2")
  File "main.go", line 44, in main
    err := WrapSecondExample()
  File "main.go", line 45, in main
    err = eris.Wrap(err, "wrap 3")

Comparison to other packages (e.g. pkg/errors)

Error formatting and stack traces

Readability is a major design requirement for eris. In addition to the JSON output shown above, eris also supports formatting errors to a simple string.

failed to get resource 'res1'
  main.GetResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:52
error not found
  main.main:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:143
  main.ProcessResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:76
  main.GetResource:/Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:52

The eris error stack is designed to be easier to interpret than other error handling packages, and it achieves this by omitting extraneous information and avoiding unnecessary repetition. The stack trace above omits calls from Go's runtime package and includes just a single frame for wrapped layers which are inserted into the root error stack trace in the correct order. eris also correctly handles and updates stack traces for global error values in a transparent way.

The output of pkg/errors for the same error is shown below. In this case, the root error stack trace is incorrect because it was declared as a global value, and it includes several extraneous lines from the runtime package. The output is also much more difficult to read and does not allow for custom formatting.

error not found
main.init
  /Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:18
runtime.doInit
  /usr/local/Cellar/go/1.13.6/libexec/src/runtime/proc.go:5222
runtime.main
  /usr/local/Cellar/go/1.13.6/libexec/src/runtime/proc.go:190
runtime.goexit
  /usr/local/Cellar/go/1.13.6/libexec/src/runtime/asm_amd64.s:1357
failed to get resource 'res1'
main.GetResource
  /Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:52
main.ProcessResource
  /Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:76
main.main
  /Users/roti/go/src/github.com/rotisserie/eris/examples/logging/example.go:143
runtime.main
  /usr/local/Cellar/go/1.13.6/libexec/src/runtime/proc.go:203
runtime.goexit
  /usr/local/Cellar/go/1.13.6/libexec/src/runtime/asm_amd64.s:1357

Migrating to eris

Migrating to eris should be a very simple process. If it doesn't offer something that you currently use from existing error packages, feel free to submit an issue to us. If you don't want to refactor all of your error handling yet, eris should work relatively seamlessly with your existing error types. Please submit an issue if this isn't the case for some reason.

Many of your dependencies will likely still use pkg/errors for error handling. When external error types are wrapped with additional context, eris creates a new root error that wraps the original external error. Because of this, error inspection should work seamlessly with other error libraries.

Contributing

If you'd like to contribute to eris, we'd love your input! Please submit an issue first so we can discuss your proposal. We're also available to discuss potential issues and features on our Discord channel.


Released under the MIT License.

Issues
  • feat: wrap external errors instead of changing them to root errors

    feat: wrap external errors instead of changing them to root errors

    this PR is a redesign of the way eris wraps external errors. instead of unwrapping them and disguising them as root errors, it simply wraps them to maintain all error context. closes #82 and closes #81.

    enhancement 
    opened by morningvera 7
  • Unpack external errors (especially coming from pkg/errors)

    Unpack external errors (especially coming from pkg/errors)

    Is your feature request related to a problem? Please describe. When getting errors from other libraries that use github.com/pkg/errors or forks of it, I noticed that the error is just flattened by calling error.Error() and then returning a rootError. This is fine for custom errors, but pkg/errors is very widespread and integration with it would make the created errors more complete.

    Describe the solution you'd like It would be nice if eris tries to unpack the error instead of just turning it into string, by recursively calling Unpack. As pkg/errors is very popular, checking for the old func Cause() error in addition to func Unpack() error would be great.

    Not just errors from pkg/errors but any error in general that implements Unpack makes sense to unpack in my opinion.

    Not sure how to unmangle the stack trace though.

    Describe alternatives you've considered

    Additional context

    enhancement 
    opened by dnaka91 7
  • Is there a way to indicate a skip level for stack in eris ?

    Is there a way to indicate a skip level for stack in eris ?

    Is your feature request related to a problem? Please describe. I would like to call eris.Wrap inside a utility Logging function but have it attribute the stack to where my function is called vs where .Wrap is called. (e.g. a typical skip level arg)

    Describe the solution you'd like I would prefer to call eris.Wrap inside mypackage.LogError instead of passing it in. But have eris skip a stack level and report one level above instead of inside my utility function.

    So imagine I have mypackage.LogError(eris.Wrap(err, "blah")); But instead I want to hide the eris.Wrap call inside mypackage.LogError(err, "blah") so that I don't have to litter my code with eris.Wrap everywhere. I want to tell eris.Wrap to skip the immediate stack frame and record the one above as the frame.

    Describe alternatives you've considered Putting mypackage.LogError(eris.Wrap()) all over my code.

    Additional context Add any other context or screenshots about the feature request here.

    enhancement 
    opened by magicalo 6
  • Add eris.As(...)

    Add eris.As(...)

    For completion, we should offer an As method like the one in Go 1.13 errors (https://golang.org/pkg/errors/#As). We should try to make this more reliable than Go's version by preventing panics: "As will panic if target is not a non-nil pointer to either a type that implements error, or to any interface type." Seems like we could just return false in these cases instead.

    enhancement good first issue 
    opened by morningvera 4
  • Missing error chain trace in Sentry

    Missing error chain trace in Sentry

    When logging to Sentry, error chain trace is missing. Text representation of wrapped errors is there, but no File:Location trace. Using provided example:

    go run examples/sentry/example.go -dsn=<Valid Sentry DSN>
    

    Results in Sentry FULL mode:

    EXCEPTION(most recent call first)
    
    *eris.rootError
    test
    *eris.wrapError
    wrap 1: test
    *eris.wrapError
    wrap 2: wrap 1: test
    *eris.wrapError
    wrap 3: wrap 2: wrap 1: test
    
    example.go in main at line 54
    	})
    	if initErr != nil {
    		log.Fatalf("failed to initialize Sentry: %v", initErr)
    	}
    	sentry.CaptureException(err)
    	sentry.Flush(time.Second * 5)
    }
    

    Results in Sentry RAW mode:

    EXCEPTION(most recent call first)
    
    *eris.wrapError: wrap 3: wrap 2: wrap 1: test
      File "example.go", line 54, in main
        sentry.CaptureException(err)
    
    bug 
    opened by Dragomir-Ivanov 3
  • Add more control over error format

    Add more control over error format

    Is your feature request related to a problem? Please describe. Currently, it is not possible to show/hide a certain part of the error frame. For ex., only show the method name or line number instead of a complete frame.

    Describe the solution you'd like One solution could be to provide some utility methods for the format object, like format.Show(file, method, line) and users can pass format.Show(true, true, false).

    Describe alternatives you've considered Another solution could be to have an object like options and users could pass options.line = false or something like that.

    enhancement 
    opened by sum2000 3
  • eris.As is incompatible with eris.Wrap

    eris.As is incompatible with eris.Wrap

    Describe the bug eris.As does not work as intended when wrapping with eris.Wrap()

    To Reproduce Run this program:

    package main
    
    import (
    	"errors"
    	"fmt"
    
    	"github.com/rotisserie/eris"
    )
    
    type X struct {
    }
    
    func (X) Error() string {
    	return "X"
    }
    
    func main() {
    	original := X{}
    
    	wrap1std := fmt.Errorf("wrap1: %w", original)
    	wrap2std := fmt.Errorf("wrap2: %w", wrap1std)
    
    	wrap1eris := eris.Wrap(original, "wrap1")
    	wrap2eris := eris.Wrap(wrap1eris, "wrap2")
    
    	var x X
    	fmt.Println(errors.As(wrap2std, &x))
    	fmt.Println(errors.As(wrap2eris, &x))
    
    	fmt.Println(eris.As(wrap2std, &x))
    	fmt.Println(eris.As(wrap2eris, &x))
    }
    

    Expected behavior The program should output true 4 times. Instead it outputs:

    true
    true
    true
    false
    

    Go: 1.16.5 Eris: github.com/rotisserie/[email protected]

    opened by aarondl0 2
  • Extend external error with stacktrace but keep the context information that error might have

    Extend external error with stacktrace but keep the context information that error might have

    When eris.Wrap is used on an external error to add a stacktrace, only its error message is preserved. The external error might already contain context information which is lost.

    Possible solution: Add a field of type error to eris.rootError and return its value on Unwrap

    Alternative: Expose funcs for creating a stacktrace to add an eris.Stack to the external error type (only applicable for owned types)

    enhancement 
    opened by philippseith 2
  • Can't us errors.As to identify an custom error which has been wrapped multiple times

    Can't us errors.As to identify an custom error which has been wrapped multiple times

    When using a custom error and then wrapping that error with eris.Wrap it's not possible to use errors.As to identify if error is made of target, even if Unwrap is implemented.

    package main
    
    import (
    	"errors"
    	"fmt"
    
    	"github.com/rotisserie/eris"
    )
    
    type AnError struct {
    	Msg string
    	Err error
    }
    
    func (ae AnError) Error() string {
    	return ae.Msg
    }
    
    func (ae AnError) Unwrap() error {
    	return ae.Err
    }
    
    func main() {
    	aerror := AnError{Msg: "invalid", Err: eris.New("eris test error")}
    	berr := eris.Wrap(aerror, "the error")
    
    	switch {
    	case errors.As(berr, &AnError{}):
    		fmt.Println("anerror")
    	}
    }
    

    I expected this code should print "anerror", if I instead wrap the error with fmt.Errorf and %w, it works as expected.

    bug 
    opened by kjico 2
  • redundant code in example

    redundant code in example

    In the doc comment you have the example code

    if eris.Is(err, NotFound) || eris.Cause(err) == NotFound 
    

    I think the second half is redundant. The only way Is returns false is if it reaches the end of the chain, which means that the last error in the chain would already have been compared to NotFound.

    documentation good first issue 
    opened by jba 2
  • Invalid mod path

    Invalid mod path

    Describe the bug The go.mod file contains the path "github.com/morningvera/eris" instead of "github.com/rotisserie/eris".

    To Reproduce go get github.com/rotisserie/eris

    Expected behavior The module is installed.

    opened by pierrec 2
  • Consider adding FromString/FromJSON methods

    Consider adding FromString/FromJSON methods

    Is your feature request related to a problem? Please describe. I'm using a message queue that utilizes gob/encoding for encoding arbitrary data into messages. I have messages that need to persist errors between various points of interaction. I would like a simple way of including errors in this, while maintaining all the stack traces and various benefits eris provides.

    Describe the solution you'd like Provide a companion API to eris.ToJSON and eris.ToString (or at least just JSON). Ideally, these functions would take the output of eris.ToJSON and when passed into the new eris.FromJSON, we get back an error (that implements the interface) and has all the relevant stack/external info from wrapping errors.

    Alternatively, you could add a companion method to eris.Unpack called eris.Pack that would take an UnpackedError and return a regular error, again keeping all the information.

    Describe alternatives you've considered Manually JSON encoding/decoding, however after crossing this boundary, no code can access the eris functions like eris.Cause, which are very useful for unwrapping.

    Thanks for considering.

    opened by ericschmar 2
  • Implement new API (from errgroup and multierror) so eris can become ultimate error package.

    Implement new API (from errgroup and multierror) so eris can become ultimate error package.

    Is your feature request related to a problem? Please describe.

    Implement new API to have only one error package to manage all common errors related cases/problems. With this change, I don't have to import other errors packages and eris would become the ultimate solution for almost all error handling cases.

    Describe the solution you'd like

    Add/Import more functions and functionalities to this pkg. I've prepared a go docs:

      // Wraps adds additional context to all error types while maintaining the type of the original error.
      //
      // This is a convenience method for wrapping errors with stack trace and is otherwise the same as Wrap(err, "").
      func Wraps(err error) error
    
      // Append is a helper function that will append more errors onto an Error in order to create a larger multi-error.
      func Append(err error, errs ...error) error
    
      // WrappedErrors returns the list of errors that this Error is wrapping.
      func WrappedErrors(err error) []error
    
      // Group is a collection of goroutines that returns errors that need to be coalesced.
      type Group struct {
        // if true group will continue execution until the last goroutine is finished.
        // It will return multierror in case of more than one error, which can be 
        // turn into the slice with WrappedErrors.
        ContinueOnError bool
      }
    
      // WithContext returns a new Group and an associated Context derived from ctx.
      func WithContext(ctx context.Context) (*Group, context.Context)
    
      // Go calls the given function in a new goroutine. It can work in two modes
      //
      // 1. The first call to return a non-nil error cancels the group
      //
      // 2. If the function returns an error it is added to the
      // group multierror which is returned by Wait.
      //
      // You can control this behavour by setting ContinueOnError in Group.
      func (g *Group) Go(f func() error)
    
      // Wait blocks until all function calls from the Go method have returned, then returns either
      // the first non-nill error (if any) or multierror. This depends on ContinueOnError setting.
      func (g *Group) Wait() error
    

    Describe alternatives you've considered

    Still using other packages like github.com/hashicorp/go-multierror or golang.org/x/sync/errgroup

    Additional context

    I know maybe this Issue should be split into smaller ones but I thought it would be easier to gather all this into one Issue.

    One real example that shows how multerror and Wraps can be used.

    
    // This is a version with comments. Below you can find two versions to compare readability.
    func (p *Postgres) ExecuteInTx(ctx context.Context, fn func(tx *Tx) error) error {
        tx, err := p.BeginTx(ctx)
        if err != nil {
            // just save a stacktrace without any message
            // it would be nice to have a function like pkgerros WithStack()
            // maybe with shorter name (eris.Stack() or eris.Wraps()),
            // to tell that I want to capture only a stack without any message.
            // right now I use Wrap for this.
            return eris.Wrap(err, "")
        }
    
        if err := fn(tx); err != nil {
            if rerr := tx.Rollback(ctx); rerr != nil {
                // "github.com/hashicorp/go-multierror"
                // It would be great to have api to combine
                // multiple errors into one. Ofc I can use
                // eris.Wrap here but it seems a bit overkill
                // to have two calls in stacktrace when in fact
                // I just need two error messages combined into one.
                // This can be used also in many other places
                err = multierror.Append(err, rerr)
            }
    
            return eris.Wrap(err, "") // eris.Wraps()
        }
    
        return eris.Wrap(tx.Commit(ctx), "") // eris.Wraps())
    }
    
    // This is version with external package and Wrap
    func (p *Postgres) ExecuteInTx(ctx context.Context, fn func(tx *Tx) error) error {
        tx, err := p.BeginTx(ctx)
        if err != nil {
            return eris.Wrap(err, "")
        }
    
        if err := fn(tx); err != nil {
            if rerr := tx.Rollback(ctx); rerr != nil {
                err = multierror.Append(err, rerr)
            }
    
            return eris.Wrap(err, "")
        }
    
        return eris.Wrap(tx.Commit(ctx), "")
    }
    
    // This is version with eris only.
    func (p *Postgres) ExecuteInTx(ctx context.Context, fn func(tx *Tx) error) error {
        tx, err := p.BeginTx(ctx)
        if err != nil {
            return eris.Wraps(err)
        }
    
        if err := fn(tx); err != nil {
            if rerr := tx.Rollback(ctx); rerr != nil {
                err = eris.Append(err, rerr)
            }
    
            return eris.Wraps(err)
        }
    
        return eris.Wraps(tx.Commit(ctx))
    }
    
    opened by krhubert 2
A Go package providing errors with a stack trace Read-only

Errors with a stack trace A Go package providing errors with a stack trace. Features: Based of github.com/pkg/errors with similar API, addressing many

null 0 Jan 7, 2022
Drop-in replacement for the standard library errors package and github.com/pkg/errors

Emperror: Errors Drop-in replacement for the standard library errors package and github.com/pkg/errors. This is a single, lightweight library merging

Emperror 136 May 10, 2022
Common juju errors and functions to annotate errors. Based on juju/errgo

errors import "github.com/juju/errors" The juju/errors provides an easy way to annotate errors without losing the original error context. The exporte

Juju 1.3k May 12, 2022
Linter for errors.Is and errors.As

erris erris is a program for checking that errors are compared or type asserted using go1.13 errors.Is and errors.As functions. Install go get -u gith

Roman Budnikov 51 Mar 3, 2022
An errors package optimized for the pkg/errors package

errors An errors package optimized for the pkg/errors package Use Download and install go get github.com/dobyte/errors API // New Wrapping for errors.

Fuxiao 3 Mar 2, 2022
Reduce debugging time while programming Go. Use static and stack-trace analysis to determine which func call causes the error.

Errlog: reduce debugging time while programming Introduction Use errlog to improve error logging and speed up debugging while you create amazing code

Martin Joly 405 May 16, 2022
Same as fmt.Errorf but with stack trace.

Annotation with stack trace for go1.13 Go 1.13 contains support for error wrapping. Now you can add additional information to an error by wrapping it

Roman Budnikov 39 Dec 25, 2020
First attempt to trace a shell script with Datadog's go tracer

dd-trace-shell First attempt to trace a shell script with Datadog's go tracer. W

Barbayar Dashzeveg 0 Dec 17, 2021
Go tool to wrap and fix errors with the new %w verb directive

errwrap Wrap and fix Go errors with the new %w verb directive. This tool analyzes fmt.Errorf() calls and reports calls that contain a verb directive t

Fatih Arslan 352 May 10, 2022
Golang errors with stacktrace and context

merry Add context to errors, including automatic stack capture, cause chains, HTTP status code, user messages, and arbitrary values. The package is la

Russ Egan 248 Apr 5, 2022
This structured Error package wraps errors with context and other info

RErr package This structured Error package wraps errors with context and other info. It can be used to enrich logging, for example with a structured l

Rohan Allison 0 Jan 21, 2022
The Emperor takes care of all errors personally

The Emperor takes care of all errors personally. Go's philosophy encourages to gracefully handle errors whenever possible, but some times recovering f

Emperror 248 Apr 17, 2022
A drop-in replacement for Go errors, with some added sugar! Unwrap user-friendly messages, HTTP status code, easy wrapping with multiple error types.

Errors Errors package is a drop-in replacement of the built-in Go errors package with no external dependencies. It lets you create errors of 11 differ

Kamaleshwar 41 May 10, 2022
A Go (golang) package for representing a list of errors as a single error.

go-multierror go-multierror is a package for Go that provides a mechanism for representing a list of error values as a single error. This allows a fun

HashiCorp 1.6k May 18, 2022
Hierarchical errors reporting done right in Golang

Hierarchical errors made right Hate seeing error: exit status 128 in the output of programs without actual explanation what is going wrong? Or, maybe,

reconquest 74 Nov 9, 2021
harvest Go errors with ease

Pears Harvest Go Errors with Ease Introduction Pears helps reduce the boilerplate and ensure correctness for common error-handling scenarios: Panic re

Billy Peake 7 Apr 25, 2021
SupErr -- Go stdlib errors with super powers

superr SupErr -- Go stdlib errors with super powers. Pronounced super with a French accent :D Build a stack of errors compatible with Go stdlib and er

Golang libraries for everyone 22 Mar 2, 2022
Package semerr helps to work with errors in Golang.

semerr Package semerr helps to work with errors in Golang. Const error An error that can be defined as const. var errMutable error = errors.New("mutab

Maxim Krivchun 3 Mar 27, 2022
A Nostress Errors Package For Golang

A Nostress Errors Package For Golang

null 0 Nov 2, 2021