As noted by Aston, Jones, et al, the proposal is combining two ideas that
are separable:
1. Allowing one-liners. I like the idea of leaving that to gofmt. I'd be
ok with requiring braces and allowing gofmt to make the decision to format
in one line or three using some reasonable criterion.
2. A test for not nil. In my view, saving a few keystrokes is not the
reason to support such a test. I've already got an editor snippet that
generates a default "if err != nil ... " clause. It just seems to me that
"on err { doSomething }" is worth allocating a keyword for the (admittedly
minor) gain in readability. Note: The actual proposal is more general than
that. It defines 'on' as a test against the zero-value for the variable's
type. I'm not sure that's a good idea. Seems messy if it were allowed to
struct types.
On Thursday, July 4, 2019 at 4:55:50 AM UTC-4, Slawomir Pryczek wrote:
>
> On one side, it's 1000x better than the other error handling specs, at
> least it isn't going to turn code into unreadable, fragmented mess. On the
> other, Aston seems to have a point, it's just replacing one-liner... and
> it's not that great at all because with "if" you know what it's doing
> without reading the spec.
>
> My point is it doesn't fix anything, it doesn't provide any clear
> benefit... it's an attempt to fix something which works great and is
> clearly not broken. So why complicate the language with a new keyword which
> has really no purpose. Maybe adding a warning about unhandled errors to VET
> would be better idea (which would probably be complicated to do properly,
> but at least it'll have some real, positive effect on code quality).
>
>
> W dniu wtorek, 2 lipca 2019 21:57:24 UTC+2 użytkownik Liam napisał:
>>
>> This proposal has attracted modest attention from the Go team...
>> https://github.com/golang/go/issues/32611
>>
>> It suggests:
>>
>> err := f()
>> on err, <single_statement>
>>
>> on err, return err // any type can be tested for non-zero
>> on err, return fmt.Errorf(...)
>>
>> on err, fmt.Println(err) // doesn't stop the function
>> on err, continue // retry in a loop
>>
>> on err, goto label // labeled handler invocation
>> on err, hname // named handler invocation
>>
>>
>>
>> And offers these possible extensions:
>>
>> on err, os.IsNotExist(err): <stmt>
>> on err, err == io.EOF: <stmt>
>> on err, err.(*os.PathError): <stmt> // doesn't panic if not a match
>>
>> on err, <condition>: <stmt>
>> on err: <stmt> // this pair provides if/else in 2 lines
>>
>> on err := f(), <stmt> // for assignment with single lvalue
>>
>>
>>
>> Other punctuation is possible, e.g. on (err) <stmt>
>>
>> Now if we could just convince the Go gods to prototype this along with
>> try() in 1.14 :-)
>>
>
--
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/adb9a65b-13a1-40e0-8b9b-b28fe80d07c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
