I apologize, I think the actual issue is with the implementation I found. Let me explain what happened to clarify:
<code> var sentinelErr = someInternalLib.NewError("something happened. The implementation of this contains a slice") type SomeInnocentErr struct {} func (e SomeInnocentErr) Error() string { return "wrapped: " + e.Err.Error() } func (e SomeInnocentErr) Is(target error) bool { return sentinelErr == target } </code> If the above sentinelErr had been defined with the standard errors.New then there had been no problem, or at least instead of doing "return sentinelErr == target" it had done something like "errors.Is(target, sentinelErr)". This is evidently an internal issue, not with the standard library, sorry about the fuzz. On Monday, 31 July 2023 at 17:22:11 UTC-3 Diego Augusto Molina wrote: > Hello everyone. In relation to standard errors package, I wanted to ask > about safe ways of implementing Is(target error) bool. The current > documentation ( > https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/errors/wrap.go;l=35) > > says the following: > > // An error type might provide an Is method so it can be treated as > equivalent > // to an existing error. For example, if MyError defines > // > // func (m MyError) Is(target error) bool { return target == fs.ErrExist } > > This seems wrong and actually leads users in the wrong direction, as if > someone implements an error type like "type MyErrs []error" then it's > sufficient to make that implementation panic, so the documentation is > leading users to create panic-prone code. While it's true that interfaces > are comparable, concrete types implementing them may not, and the error > will happen at runtime. > > Note that the code for the Is function in errors package actually uses > reflectlite.TypeOf(target).Comparable() > to avoid these panics, but that as users do not have access to reflectlite > and, even if they do, the documentation is not warning against these > possible panics, then it's very easy to make mistakes. Of course, nil > comparisons are ok, because the comparison is of the value of the > interface, not the value of the concrete type. > > I propose: consider changing the documentation to warn users against this > possible problem when implementing the Is method of their own error types. > > My question to the community: how do you currently go about this issue. > > Thank you. > -- 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 https://groups.google.com/d/msgid/golang-nuts/82a6f529-e6c1-4c45-b49e-363691366466n%40googlegroups.com.