In some ways, the existing API is arguably more ergonomic than the originally proposed generic version, as it's possible to use `errors.As` in a switch statement (eg to test several possible types of error) which isn't possible with the multi-return `As` variant.
A minor variant of the existing API could be: ``` func As[E error](err error, asErr *E) bool ``` which makes the API a little clearer without changing the usage. Sadly we can't make that change without breaking compatibility. On Sun, 19 Sep 2021, 21:15 David Finkel, <david.fin...@gmail.com> wrote: > > > > On Sun, Sep 19, 2021 at 4:02 PM David Finkel <david.fin...@gmail.com> > wrote: > >> You might be interested in the original draft proposal for errors.As: >> >> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions >> >> In particular, it originally specified that errors.As would take a >> type-parameter. (the version of generics that was proposed concurrently >> with that proposal was not accepted so they had to go with the current >> (clunkier) interface). >> > > Hmm, actually, the code in that proposal for the generic version of > errors.As works almost unchanged: > https://go2goplay.golang.org/p/ddPDlk00Cbl (I just had to change the > type-parameter syntax) > > >> On Sun, Sep 19, 2021 at 5:33 AM Haddock <ffm2...@web.de> wrote: >> >>> >>> I like the way error handling is done in the xerror package. Things >>> become more concise, but remain very easy to read and understand as in >>> plain Go errorhandling. >>> >>> Here is the example of how to use xerror.As: >>> >>> _, err := os.Open("non-existing") >>> if err != nil { >>> var pathError *os.PathError >>> if xerrors.As(err, &pathError) { >>> fmt.Println("Failed at path:", pathError.Path) >>> } >>> } >>> >>> My idea is to make this even shorter like this: >>> >>> _, err := os.Open("non-existing") >>> myerrors.As(err, os.PathError) { >>> pathError -> fmt.Println("Failed at path:", pathError.Path) >>> } >>> >>> Think something like that has so far not been suggested. That's why I >>> thought it is justified to drop comment. >>> >>> myerrors.As would also do the check if err is nil. The code in my sample >>> is not valid Go code, I know. It is only pseudo code to show the idea. >>> >>> -- >>> 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/629e6763-36a9-4d7d-991c-fd71dd384d0en%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/629e6763-36a9-4d7d-991c-fd71dd384d0en%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/CANrC0BgsVSo0hv5UtTi%3DVXZYZODys1H-kvB63o2B3UThBMnfxQ%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CANrC0BgsVSo0hv5UtTi%3DVXZYZODys1H-kvB63o2B3UThBMnfxQ%40mail.gmail.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/CAJhgaci_b%3DX0wn1R4gmT3Dgv3Ztbf4zb_S5X-tpMbezWgHU35A%40mail.gmail.com.
