... 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.
