-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wish we could tell if the append happened #21
Labels
Comments
at15
added a commit
to dyweb/gommon
that referenced
this issue
Feb 25, 2018
at15
added a commit
to dyweb/gommon
that referenced
this issue
Feb 25, 2018
[errors] Replace pkg/errors Fix #54 - multi error and wrap error - multi error `Append(err error)` returns true if it got a non nil error uber-go/multierr#21 - `Wrap` would reuse stack if the underlying error has one pkg/errors#122, and if `Frames()` is not called, `runtime.Frames` would not be expanded to `[]runtime.Frame`
I'm in favor of func AppendInto(into *error, err error) (errored bool) The surface area is small, and the possibility of misuse is acceptable. A PR would be welcome. |
abhinav
added a commit
that referenced
this issue
Nov 4, 2019
This adds an AppendInto function that behaves similarly to Append except, it operates on a `*error` on the left side and it reports whether the right side error was non-nil. func AppendInto(*error, error) (errored bool) Making the left side a pointer aligns with the fast path of `Append`. Returning whether the right error was non-nil aligns with the standard `if err := ...; err != nil` pattern. ```diff -if err := thing(); err != nil { +if multierr.AppendInto(&err, thing()) { continue } ``` Resolves #21
Merged
abhinav
added a commit
that referenced
this issue
Nov 4, 2019
This adds an AppendInto function that behaves similarly to Append except, it operates on a `*error` on the left side and it reports whether the right side error was non-nil. func AppendInto(*error, error) (errored bool) Making the left side a pointer aligns with the fast path of `Append`. Returning whether the right error was non-nil aligns with the standard `if err := ...; err != nil` pattern. ```diff -if err := thing(); err != nil { +if multierr.AppendInto(&err, thing()) { continue } ``` Resolves #21
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've hit a surprising number of cases recently where I wished that
multierr.Append
would tell me if the append happened or not. It's not so much for dubious micro perf reasons (CPUs being cheap, fast, and plentiful these days), but more on account of simplifying control flow:err = multierr.Append(err, somethingFaliable())
somethingFaliable
failed or not in addition to collecting its error, then I have to break that apart, and do my own nil checksomeErr
;-)The text was updated successfully, but these errors were encountered: