3 ms·

> errors.Is is true for whatever x.Close() returned. That may get you through if there is only one x.Close, but now you have to offer the guarantee to the call

> errors.Is is true for whatever x.Close() returned. That may get you through if there is only one x.Close, but now you have to offer the guarantee to the callers that there will only ever be one Close error returned. Furthermore, any callers of your function have to ensure that they don't end up introducing additional Close error returns in the same vein. Without such guarantees, you, the caller, need to resort to string matching to protect against undocumented functionality and/or future modifications when you handle the error. Sounds like a rough situation... > If I'm going to do something upstream based on the error, I use a type. Implying that you are a lone wolf developer? I think you make a good point that if you exist in your own world without other developers just about anything goes. That said, the language used around the previously linked repository implies that it welcomes other developers using and working on the code, so it is not clear how you are "doing the upstream" in all cases.

jrockway 2y ago
> That may get you through if there is only one x.Close, but now you have to offer the guarantee to the callers that there will only ever be one Close error returned. No you don't. It's a multierror, a feature of the standard library. errors.Is( errors.Join(ErrA, ErrB, ErrC, errors.Join(ErrD, ErrE, ErrF)), ErrF) is true. This is a feature in the standard library. > Implying that you are a lone wolf developer? You know that's not true from the history of the repository. We do have coding standards that reviewers enforce, this is one of them.
- randomdata 2y ago
  > It's a multierror, a feature of the standard library. Understood (I read the code), but that doesn't help, and really has nothing to do with the topic at hand. Is the problem here that you don't have an understanding of what we're talking about? > You know that's not true from the history of the repository. Which is why the claim was identified as being strange and in need of clarification. How can "If I'm going to do something upstream based on the error, I use a type." be true? If there are many developers, you don't get to control the upstream.

jrockway 2y ago

> That may get you through if there is only one x.Close, but now you have to offer the guarantee to the callers that there will only ever be one Close error returned. No you don't. It's a multierror, a feature of the standard library. errors.Is( errors.Join(ErrA, ErrB, ErrC, errors.Join(ErrD, ErrE, ErrF)), ErrF) is true. This is a feature in the standard library. > Implying that you are a lone wolf developer? You know that's not true from the history of the repository. We do have coding standards that reviewers enforce, this is one of them.

randomdata 2y ago
> It's a multierror, a feature of the standard library. Understood (I read the code), but that doesn't help, and really has nothing to do with the topic at hand. Is the problem here that you don't have an understanding of what we're talking about? > You know that's not true from the history of the repository. Which is why the claim was identified as being strange and in need of clarification. How can "If I'm going to do something upstream based on the error, I use a type." be true? If there are many developers, you don't get to control the upstream.