Here are some examples for valid error returns according to my proposal:
file, err := os.Open(fname) ||| return err
file, err := os.Open(fname) ||| panic(err)
file, err := os.Open(fname) ||| return errors.Wrap(err, "too bad")
The third example uses the Wrap function from github.com/pkg/errors. The
||| operator is not important. It could be any operator, but the idea
behind the tripple bar is to signal a special kind of or. I can imagine
using the keyword "orr" instead.
The semantics is pretty simple. If there is an (possibly multiple)
assignment whose last component conforms to the error interface, then it
may be followed by ||| and a single statement that must either return or
panic.
You might argue that this isn't much longer:
if file, err := os.Open(fname); err != nil {
return err
}
However, this has the unfortunate side effect of putting file into the
scope of the if block. That's why we often have to use
file, err := os.Open(fname)
if err != nil {
return err
}
I think my proposal has a couple of benefits.
- It is perhaps not too magical (just a little bit because the condition
is implied by the ||| operator).
- I doesn't obscure the clear view on the assignment statement itself
(unlike Rust's try! macro).
- The keywords return or panic make it very clear what happens to
control flow (unlike Rust's try! macro).
It does have the drawback that it is a unique special case for errors not
based on a more general language facility. It makes the language a little
bit more complex. But I think errors are frequent enough to deserve a
little bit of syntactic sugar.
Apologies if this has been discussed to death.
--
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.
For more options, visit https://groups.google.com/d/optout.
