go-multierror alternatives and similar packages
Based on the "Miscellaneous" category.
Alternatively, view go-multierror alternatives based on common mentions on social networks and blogs.
-
ghorg
Quickly clone an entire org/users repositories into one directory - Supports GitHub, GitLab, Bitbucket, and more 🥚 -
go-restful-api
An idiomatic Go REST API starter kit (boilerplate) following the SOLID principles and Clean Architecture -
container
A lightweight yet powerful IoC dependency injection container for the Go programming language -
gountries
Gountries provides: Countries (ISO-3166-1), Country Subdivisions(ISO-3166-2), Currencies (ISO 4217), Geo Coordinates(ISO-6709) as well as translations, country borders and other stuff exposed as struct data. -
go-starter
An opinionated production-ready SQL-/Swagger-first RESTful JSON API written in Go, highly integrated with VSCode DevContainers by allaboutapps. -
countries
Countries - ISO-639, ISO-3166 countries codes with subdivisions and names, ISO-4217 currency designators, ITU-T E.164 IDD phone codes, countries capitals, UN M.49 codes, IANA ccTLD countries domains, FIPS, IOC/NOC and FIFA codes, VERY VERY FAST, compatible with Databases/JSON/BSON/GOB/XML/CSV, Emoji countries flags and currencies, Unicode CLDR.
WorkOS - The modern identity platform for B2B SaaS
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of go-multierror or a related project?
README
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 function in Go to return an error
that might actually
be a list of errors. If the caller knows this, they can unwrap the
list and access the errors. If the caller doesn't know, the error
formats to a nice human-readable format.
go-multierror
is fully compatible with the Go standard library
errors package, including the
functions As
, Is
, and Unwrap
. This provides a standardized approach
for introspecting on error values.
Installation and Docs
Install using go get github.com/hashicorp/go-multierror
.
Full documentation is available at https://pkg.go.dev/github.com/hashicorp/go-multierror
Requires go version 1.13 or newer
go-multierror
requires go version 1.13 or newer. Go 1.13 introduced
error wrapping, which
this library takes advantage of.
If you need to use an earlier version of go, you can use the v1.0.0 tag, which doesn't rely on features in go 1.13.
If you see compile errors that look like the below, it's likely that you're on an older version of go:
/go/src/github.com/hashicorp/go-multierror/multierror.go:112:9: undefined: errors.As
/go/src/github.com/hashicorp/go-multierror/multierror.go:117:9: undefined: errors.Is
Usage
go-multierror is easy to use and purposely built to be unobtrusive in existing Go applications/libraries that may not be aware of it.
Building a list of errors
The Append
function is used to create a list of errors. This function
behaves a lot like the Go built-in append
function: it doesn't matter
if the first argument is nil, a multierror.Error
, or any other error
,
the function behaves as you would expect.
var result error
if err := step1(); err != nil {
result = multierror.Append(result, err)
}
if err := step2(); err != nil {
result = multierror.Append(result, err)
}
return result
Customizing the formatting of the errors
By specifying a custom ErrorFormat
, you can customize the format
of the Error() string
function:
var result *multierror.Error
// ... accumulate errors here, maybe using Append
if result != nil {
result.ErrorFormat = func([]error) string {
return "errors!"
}
}
Accessing the list of errors
multierror.Error
implements error
so if the caller doesn't know about
multierror, it will work just fine. But if you're aware a multierror might
be returned, you can use type switches to access the list of errors:
if err := something(); err != nil {
if merr, ok := err.(*multierror.Error); ok {
// Use merr.Errors
}
}
You can also use the standard errors.Unwrap
function. This will continue to unwrap into subsequent errors until none exist.
Extracting an error
The standard library errors.As
function can be used directly with a multierror to extract a specific error:
// Assume err is a multierror value
err := somefunc()
// We want to know if "err" has a "RichErrorType" in it and extract it.
var errRich RichErrorType
if errors.As(err, &errRich) {
// It has it, and now errRich is populated.
}
Checking for an exact error value
Some errors are returned as exact errors such as the ErrNotExist
error in the os
package. You can check if this error is present by using
the standard errors.Is
function.
// Assume err is a multierror value
err := somefunc()
if errors.Is(err, os.ErrNotExist) {
// err contains os.ErrNotExist
}
Returning a multierror only if there are errors
If you build a multierror.Error
, you can use the ErrorOrNil
function
to return an error
implementation only if there are errors to return:
var result *multierror.Error
// ... accumulate errors here
// Return the `error` only if errors were added to the multierror, otherwise
// return nil since there are no errors.
return result.ErrorOrNil()