I'm using golang v1.12 but this package is not supported because of errors.Is and errors.As functions which are not present in v1.12 and was added in v1.13. And there is no version requirement mentioned in the documentation. for this package

It does not work since go.mod specifies [email protected] and it does not have Unwrap(), but Unwrap() was added in [email protected].

I could obviously fix it explicilty by updating versions but fixing it in go.mod wouldn't hurt either.

When the program is processed in multiple goroutines, panic may occur, which will cause main goroutine to crash directly. Can following logic add to Group.Go() ?

// Go calls the given function in a new goroutine.
//
// If the function returns an error it is added to the group multierror which
// is returned by Wait.
func (g *Group) Go(f func() error) {
	g.wg.Add(1)

	go func() {
		defer g.wg.Done()

+		defer func() {
+			if r := recover(); r != nil {
+				g.mutex.Lock()
+				g.err = Append(g.err, fmt.Errorf("%v", r))
+				g.mutex.Unlock()
+			}
+		}()

		if err := f(); err != nil {
			g.mutex.Lock()
			g.err = Append(g.err, err)
			g.mutex.Unlock()
		}
	}()
}

Hi, thanks for maintaining this library

I'd like to use this library to return errors to a caller that would prefer no newlines if possible (in the event of one error). That is doable and looks like this:

func Foo() error {
	var retErr *multierror.Error
	for _, x := range getSlice() {
		if err := bar(x); err != nil {
			retErr = multierror.Append(retErr, err)
		}
	}
	return decorateFormat(retErr.ErrorOrNil())
}

func decorateFormat(err *multierror.Error) *multierror.Error {
	if err != nil {
		err.ErrorFormat = multierror.ErrorFormatFunc(func(errs []error) string {
			if len(errs) == 1 {
				return errs[0].Error()
			}
			return multierror.ListFormatFunc(errs)
		})
	}
	return err
}

Which is fine, but requires me to remember to set the listFormatFunc, I'm doing that in a separate "decorator" func because I will need to do this many times.

I would like to make it possible to specify the "default" error func so I don't have to remember to set it. This way, whenever a new multierror.Error was created, it would automatically have the format function I want. Would you accept a change like that? If so, perhaps a default global (defaults to the current ListFormatFunc) is the way to go, but would defer to you. Thanks in advance!

Workflow Name: hashicorp/go-multierror/go-multierror
Branch: main
Run URL: https://github.com/hashicorp/go-multierror/actions/runs/4621539068

save-state deprecation warnings: 0
set-output deprecation warnings: 1
node12 deprecation warnings: 1

Please review these deprecation warnings as soon as possible and merge in the necessary updates.

GitHub will be removing support for these commands and plan to fully disable them on 31st May 2023. At this time, any workflow that still utilizes these commands will fail. See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/.

GitHub have not finalized a date for deprecating node12 yet but have indicated that this will be summer 2023. So it is advised to switch to node16 asap. See https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.

If you need any help, please reach out to us in #team-rel-eng.

Loving this library. One thing surprised me though:

var err error
var err2 error
err = multierror.Append(err, err2)
// err.Error() "0 errors occurred:"

Practically speaking, instead of doing this:

var err error
for _, chrome := range m.chromes {
	err = multierror.Append(err, chrome.Stop())
}
return err

You have to do this:

var err error
for _, chrome := range m.chromes {
	e := chrome.Stop()
	if e != nil {
		err = multierror.Append(err, e)
	}
}
return err

Not terrible, just a bit unexpected. Would you accept a PR fixing this? Thanks!

If I have a bunch of goroutines adding to the same multierror.Error type, would this cause problems if I don't wrap it with a mutex?

Hey,

I am using your multierror package in my project however I need to wrap it and add a MarshalJSON as it doesn't Marshal out of the box (because of the Func field). Would it be ok to add it to your project? In my case it would just marshal the error array. I don't know if you would want to do something more elaborate

go get github.com/hashicorp/go-multierror

github.com/hashicorp/go-multierror

../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

go version
go1.10.4 linux/amd64

chain.Unwrap() has a test to see whether the end of the chain has been reached. I don't understand this; is it correct?

multierror.go:

// Unwrap implements errors.Unwrap by returning the next error in the
// chain or nil if there are no more errors.
func (e chain) Unwrap() error {
	if len(e) == 1 {  // line 106
		return nil
	}

	return e[1:]
}

It seems to me that line 106 might have a mistake and should be if len(e) < 1 {.

Have I misunderstood this?

I am using v1.1.1.

When I update this package
go get -u github.com/hashicorp/go-multierror
It was failed.
# github.com/hashicorp/go-multierror
../../hashicorp/go-multierror/multierror.go:112:9: undefined: errors.As
../../hashicorp/go-multierror/multierror.go:117:9: undefined: errors.Is

The As and Is are not in the errors package.
Go SDK: 1.10.2

Hi!

I have an in-review proposal to add support for wrapping multiple errors to the standard library. The latest version of the proposal is:
golang/go#53435 (comment)

This proposal is intended to allow interoperation between multierror implementations, as well as to simplify these implementations. It isn't intended to supplant existing implementations, except in the simplest of cases. The quick summary of the proposal is that errors.Is and errors.As would support descending into multiple errors when a type implements an Unwrap() []error method returning a list of wrapped errors; for details see the above link.

I'm opening an issue in this repo to invite your comments on this proposal, either in the proposal issue or here. Would you find this feature useful? If adopted, would you add an Unwrap() error to your error types? Do you see any problems with this proposal, or are there changes that would make it more useful to you?

Thanks!

At the moment, Append never returns nil. The use case I've run across is the following, where a function returns an array of errors, and it's necessary to return an error if any of them are non-nil.

result, errs := multierrorFunc()
if err := multierror.Append(nil, errs...); err != nil {
	return err
}

I think all that would be needed is to add a check for the length of the error list and update this test.

if len(err.Errors) == 0 {
	return nil
}

If this seems like non-breaking functionality that would be useful, I could submit a pull request.

Thanks all!

I am trying to build mxpv/podsync using its makefile, and I am getting this error:

# github.com/hashicorp/go-multierror
../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

I know basically nothing about go, but as far as I can tell this shouldn't be happening. Is this a bug in the podsync makefile, or is it a bug in multierror.go?

I would appreciate the attention of someone who understands these things better than I. Thanks!

(For further context, see my issue on the podsync repository here.)

Hello, thanks for a useful library. Am I correct that it doesn't appear to provide unique competitive advantage to Hashicorp?

Could it (and hashicorp/errwrap) be changed to a permissive license? That would resolve the only persistent error in our binary scanners... Thanks for your consideration!

https://pkg.go.dev/errors#Join was introduced in Go 1.20.

Can someone clarify how multierror.Append is better or different? It looks like it's been superseded 🤔 https://go.dev/play/p/6oWfiUJSNx3

Thank you 😄

Can you make a new release, including Group in order to make it available in go modules? It is already present in your documentation, so I think, that it is reasonable to include it in a new release.

It was last released in 2021.

Please publish a new version.

As of now the method can be called only on a not nil Error.

I stumbled upon the situation where I wanted handle how many errors a multierror variable contained, however Len can't be called on a nil multierror (which would cause a runtime panic).

This implies that a nil multierror and zero length multierror are treated differently. I would expect the example in the playground to return 0 instead of throwing a panic. Is this an intentional design choice or maybe there is room for improvement?

https://play.golang.org/p/n7fwsjBybhs

The Len() method could be changed as the following without breaking changes (I think):

func (err *Error) Len() int {
	if err != nil {
		return len(err.Errors)
	}

	return 0
}

Otherwise one would need to go through the ErrOrNil method with little, although not needed, overhead.

         var merr *multierror.Error
	if merr.ErrOrNil != nil {
		fmt.Println(merr.Len())
	} else {
		fmt.Println("0")
	}

I should also add that his condition happens when a multierror is initialized but nothing has been appended to it, in fact appending nil errors correctly fills it with zeroes.
https://play.golang.org/p/B3P_aNnms2W

It's not uncommon to see code like this:

package main

import (
	"github.com/hashicorp/go-multierror"
)

type server struct{}

func (s *server) Run() error {
	g := new(multierror.Group)
	g.Go(
		func() error {
			// ...code to do some work here...
			return nil
		},
	)
	g.Go(
		func() error {
			// ...code to do some MORE work here...
			return nil
		},
	)
	return g.Wait()
}

func main() {
	s := server{}
	if err := s.Run(); err != nil {
		panic("error while running")
	}
}

However, there is a subtle bug here. The main function will always panic, despite no error being returned by any of the Goroutines managed by the group g. This is due to the fact that Go treats interfaces as "fat pointers". See:

• https://golang.org/doc/faq#nil_error
• https://tour.golang.org/methods/12
• https://guihao-liang.github.io/2020/07/05/interface-type-value
• https://glucn.medium.com/golang-an-interface-holding-a-nil-value-is-not-nil-bb151f472cc7
• https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/#nil-interface-values

A "fix" is to add the following nil check to the Run method above:

func (s *server) Run() error {
	g := new(multierror.Group)
	g.Go(
		func() error {
			// ...code to do some work here...
			return nil
		},
	)
	g.Go(
		func() error {
			// ...code to do some MORE work here...
			return nil
		},
	)
	if err := g.Wait(); err != nil {
		return err
	}
	return nil

	//... or alternatively: return g.Wait().ErrorOrNil()
}

This is certainly not intuitive, and relies on type-inference to solve the problem. I've added a test to my fork of this repo to clearly demonstrate the issue:

• https://github.com/ccampo133/go-multierror/pull/1/files

My question - is there a good reason why Group.Wait returns *Error instead of just error, which is more idiomatic? Returning error would eliminate this weirdness seen here.

There are many cases where a call to some library returns []error.

Given this use case, utilising go-multierror is problematic as the client must check for an initial error, and if there are any remaining, then use Append.

This proposal removes this requirement from the client and adds an alternative (non-BC breaking) API change to allow a list of errors to be given.

Proposed signature:

AppendList(errs ...[]error)

All functionality would be identical, except that providing no errors would return an empty Error.

When we have an array of errors we want to combine into a single one, we need to do the following:

func Errs() error {
    errs := []errors{}
    ...
    if len(errs) > 1 {
        return multierror.Append(keyErrs[0], keyErrs[1:]...)
    }
    return errs[0]
}

Or we can create a loop to build:

func Errs() (errs error) {
    builtErrs := []errors{}
    ...
    for _, err := range builtErrs {
        errs = multierror.Append(errs, err)
    }
    return errs
}

Instead of having to check length or use ranges, might be nice to have a Join function that takes an array of errors regardless of size:

func Errs() error {
    errs := []errors{}
    ...
    return multierror.Join(errs)
}

Notably I came across this issue in a situation where I need to know the number errors before returning, hence I need to use an error slice when initially building the errors rather than use Append directly.

I realize that Append() was fixed at some point to flatten, but I believe it's valuable to have a version of it that does not flatten MultiErrors. Use case: execute a bunch of tasks in parallel, wait for them to finish, collect the errors from the failed tasks and return them to the caller as a single MultiError. I would like to be able to preserve any MutliError generated by each task rather than ending up with a flat list of errors that lost their context, the demarcation points between tasks if you will.