On Mon, Sep 20, 2021 at 10:52 PM Andrey T. <xnow4fippy...@sneakemail.com>
wrote:
>
> ... 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...
That's not a particularly crazy idea. It's just one that's unlikely to make
it through with one use-case like this since the bar for language changes
is so much higher than standard library changes. (for good reason)
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
> <https://groups.google.com/d/msgid/golang-nuts/8f81d126-5be5-464a-9284-0aca02631c42n%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/CANrC0BjBWqtN0Dx4J6Bad5eJSnks3KXxpGYYcYcB%2BUf1vg847Q%40mail.gmail.com.
