Ah, think I found it: https://blog.golang.org/go1.13-errors says:
In the simplest case, the errors.Is function behaves like a comparison to a sentinel error, and the errors.Asfunction behaves like a type assertion. When operating on wrapped errors, however, these functions consider all the errors in a chain. So I should just use errors.Is here... Sorry for the confusion! On Monday, August 2, 2021 at 10:02:11 AM UTC+2 cpu...@gmail.com wrote: > Consider this example: https://play.golang.org/p/16cU0kc8Lku, basically > > var Err = errors.New("sentinel") > err := errors.New("foo") > if errors.As(err, &Err) { > fmt.Println("why?") > } > > I'm wondering why this matches the sentinel error, or rather how to > properly use sentinel errors. errors.As says "An error matches target if > the error's concrete value is assignable to the value pointed to by > target". This seems to be the case here (both are of type error). > > However, if thats the case, how should I construct a sentinel error that > would be usable with errors.As? I don't want to rely on errors.Is as errors > could be wrapped. So to "break" the assignability- would that mean that I'd > need to define sentinel errors as e.g. struct types? > > Seem's I'm still lacking the level of understanding for go errors that I'd > aspire to :/ > > 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/7a495842-a022-4c41-92aa-39e8dff00f97n%40googlegroups.com.
