That is not always true. I saw code that looks like this a few days ago:
what the author was trying to do was to handle a specific type of error
differently, and pass it along if the error is some other type:
type CustomError struct{}
func (e CustomError) Error() string { return "error" }
func g() error {...}
func f() (error, bool) {
err, ok := g().(CustomError)
if ok {
return err, true
}
return err, false
}
https://go.dev/play/p/YoIjKtoynuI
On Thu, Sep 22, 2022 at 11:38 AM Martin Schnabel <m...@mb0.org> wrote:
> Sorry, to barge in but this specific thing is not really an issue as
> long as you use the error type as result type. because any value with an
> Error() string method does implement the error interface. and even an
> empty struct or a nil pointer to a applicable type will do just fine an
> matches err != nil
>
> have fun
>
> On 9/22/22 17:29, Tamás Gulácsi wrote:
> > plain struct error is brittle in other ways, too: you can shoot yourself
> > on foot with "err != nil" check.
> > So: error should be a pointer type.
> >
> > cpu...@gmail.com a következőt írta (2022. szeptember 21., szerda,
> > 21:26:31 UTC+2):
> >
> > Consider https://go.dev/play/p/jgPMwLRRsqe
> > <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
> > <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/b9d94e2f-860e-44eb-9f9e-efcd0a82b7d2n%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/b9d94e2f-860e-44eb-9f9e-efcd0a82b7d2n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
> --
> 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/84507652-eabc-c149-bdfb-8032657536ed%40mb0.org
> .
>
--
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/CAMV2Rqp0wPvgMoH8ZnmbGEQf5PGzO2ySy1wG9pXkh3Jbkyii6w%40mail.gmail.com.
