On Tuesday, September 3, 2019 at 8:29:36 PM UTC-7, Abhinav Gupta wrote:

> The PR we have open <https://github.com/uber-go/multierr/pull/28> 
> implements the following behavior:
>    - For errors.As, the first error in the list where errors.As succeeds 
>    is
>    returned. 
>    - For errors.Is, all errors are checked until one matches, in which 
>    case we
>    succeed. If none of the errors matched, we fail. 
> This means that if you have multiple os.PathErrors, you can use errors.As
> to extract the first of those, and you can use errors.Is to match for
> equality against any of those.
> What we’d like to ask the community and the Go Developers is whether this
> behavior is what you would expect from a combined error tree like this.

At HashiCorp, we have our own lib go-multierror 
<https://github.com/hashicorp/go-multierror> and we were recently 
discussing the same thing. So thank you for opening this thread and 
appealing to the broader Go community.

We came to the same conclusions as you did, to the exact behavior. It seems 
the most reasonable to me given the current interface definitions.

So I just want to say I agree, and would love to hear from anyone else how 
they feel. 


> Thanks.
> Abhinav

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to