On Saturday, February 8, 2020 at 10:55:10 AM UTC-7, Brian Candler wrote:
>
> On Saturday, 8 February 2020 10:33:03 UTC, addi t0t08 wrote:
>>
>> No, 'pass' accepts an error type. in this case Foo function must return
>> an error type otherwise that would be a compile error.
>>
>>
> Ah I see: you are relying on the behaviour of errors.Wrap(nil, "dontcare"),
> which is valid and returns nil. That's a bit of hidden magic.
>
>
If you think about it, there is really no magic to it.
pass nil
doesn't do anything.
pass errors.New("some error")
Works.
Pass only cares about whats being evaluated. If there is an error, it will
return it. Otherwise, nothing happens.
To me, this is much more elegant than trying to add another keyword such as
`handle` ... etc.
With pass, you can even add logging in the error wrapper function, stack
traces ... etc. and should work fairly easily with existing error logging &
handling libraries.
> - What would "pass" return for the int and bool arguments - the zero value
> for each perhaps?
> - What would it do instead if these were named return values? Would it
> return the values already assigned, or always zero values?
>
> To me, this seems to be hidden magic, when compared with the original if
> statement, which has absolutely unambiguous semantics.
>
>
- It will return their zero values.
- Similar to proposed try built-in
<https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md#proposal>,
they would keep whatever values they have.
> Aside: I suppose it's worth mentioning that in principle golang lets you
> do this:
>
> if f, err := os.Open(filename); err != nil {
> return 0, false, SomeError
> }
>
> However, this form isn't as useful as it first appears, because "f" drops
> out of scope after the "if" statement. You can put the rest of your code
> inside an "else" block; or you can pre-declare your variables before the
> "if" statement. Either way is more work than it saves.
>
> var f, g *os.File
> var err error
> if f, err = os.Open(file1); err != nil {
> return 0, false, SomeError
> }
> defer f.Close()
> if g, err = os.Open(file2); err != nil {
> return 0, false, SomeError
> }
> defer g.Close()
> ... etc
>
Yes but with pass, i think there would be no need to do it that way.
Also, without any additional changes to the language. Go already allows
separating statements with semicolons, so it would be even possible to do
the following.
f, err := os.Open(file1) ; pass err
defer f.Close()
g, err := os.Open(file2) ; pass err
defer g.Close()
.....
but I'm not sure if that would be a preferred style because it may not be
possible to set breakpoints that way.
Even if its on a new line, it is a lot less code, and looks more readable
to be honest.
--
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/0890fdc7-8048-4c44-a3a1-455c2248a0b9%40googlegroups.com.
