If some func advertises the type of error it returns, it should mention the precise type. That is, if a function returns *ABC in error conditions, it should document that it returns *ABC (not ABC, that is a different type).
Why is that no sufficient? An API already must document the type of error they are returning, otherwise you shouldn't be depending on those internal implementation details anyway, so I see the problem of checking for "*ABC" vs "ABC" no different than the problem of checking for "SomeError" and "AnotherRandomErrorType": you must rely on the documentation to be correct in all cases. On Wednesday, September 21, 2022 at 1:26:31 PM UTC-6 cpu...@gmail.com wrote: > Consider https://go.dev/play/p/jgPMwLRRsqe: > > errors.As(err, <plain type>) will not match if error is of pointer type. > As a result, a library consumer needs to understand if a library returns > Error or *Error. However, that is not part of the API spec as both returns > would satisfy error if Error() is implemented on the plain type. > > A potential workaround would be using Error.As(any) to match plain/pointer > type as part of the library. However, it seems counterintuitive having to > do so if errors.As() doesn't by default. > > Would it make sense (and I would like to propose) to expand errors.As() to > match plain receiver types even when err is a pointer to the same > underlying plain type. > > What do you think? > > Cheers, > Andi > -- 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/d4a346d2-5ccd-4bc5-a3b9-0772e9be39f7n%40googlegroups.com.
