... or, to put a crazy idea out there, we need to ask for extension of switch statement to support (v, err) tuples for a case argument... On Sunday, September 19, 2021 at 3:43:36 PM UTC-6 david....@gmail.com wrote:
> On Sun, Sep 19, 2021 at 5:19 PM roger peppe <rogp...@gmail.com> wrote: > >> 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. >> > > Hmm, that's a good point. > However, the main reason I like the two-return-value version more is that > you can use it like a normal type-assertion in an if-statement's init > section. > > >> 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. >> >> Unfortunately, in order to use this proposed version, you still need to > pre-declare the variables for each type before the switch/case. > I've honestly found it more ergonomic to use a if/else if/ block rather > than a switch/case because it lets me contain the scope of these variables > anyway. > > I suppose a simple wrapper that can be used with type-assertions inside a > switch/case block would be: > ``` > func AsBool[E error](err error, asErr error) bool { > ae, ok := As[E](err) > if ok { > asErr = ae > } > return ok > } > ``` > (this would definitely need a better name) > > Then you'd be able to almost treat your switch/case like a type-switch > without needing to pre-declare a variable for every case. > > ``` > var asErr error > switch { > case errors.AsBool[*os.PathError](err, &asErr): > fmt.Printf("Path Error! ae: %v", asErr.(*os.PathError)) > case errors.AsBool[syscall.Errno](err, &asErr): > fmt.Printf("ae: %d", asErr.(syscall.Errno)) > } > ``` > > However, I think it would be nicer to use the (originally proposed) > two-return errors.As with if/else if. > > ``` > if pe, ok := errors.As[*os.PathError](err); ok { > fmt.Printf("Path Error: %v", pe) > } else if en, ok := errors.As[syscall.Errno](err); ok { > fmt.Printf("errno %[1]d: %[1]s", en) > } > ``` > > Since it looks like the dev.typeparams branch has been merged into master, > I was just thinking about how we'd add the two-return-value/generic version > of As to the errors package (for go 1.18). > Given that the original proposal's code works pretty much as-is, I think > the biggest barrier would be a good name. (given that As is already taken) > >> >> On Sun, 19 Sep 2021, 21:15 David Finkel, <david....@gmail.com> wrote: >> >>> >>> >>> >>> On Sun, Sep 19, 2021 at 4:02 PM David Finkel <david....@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 <ffm...@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...@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...@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/8f81d126-5be5-464a-9284-0aca02631c42n%40googlegroups.com.