x, err = some_func(); if err != nil { } seems awkward

[lgo...@gmail.com]

?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # arbitrarily chosen

[Michael Jones]

Before you get an avalanche of emails about "that is an old question, discussed in design documentation, mailing lists, and extension discussions over a decade", let me ask you to consider a concept that your comment implies.

For that to work, it means that a function call either succeeds or fails. If it succeeds, then that's that. If it fails, then something special happens. Your "#" means "do this only if the function call failed." In that case itmust be true that functions have a notion of success and failure, that the cause of failure is invisibly returned and available as an extra "and here's why it failed" return value, and, new language concepts are required to access the value of the invisible return inside that "#{ ... }" block.

There is good precedent for the S (success) and F (failure) outcomes of function calls--SNOBOL has that.

For everything else though, it has generally considered more awkward than the present situation. If you want to contribute along these lines, think about how to make the access to the invisible error return value feel natural. (maybe think about it before reading the hundreds of pages of discussion that await you.

Michael

On Thu, Jun 4, 2020 at 8:43 AM <lgo...@gmail.com> wrote:

?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # arbitrarily chosen

--
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/ea305494-c6ec-46f9-962d-9add01edc8bd%40googlegroups.com.

--

Michael T. Jones
michae...@gmail.com

[Saied Seghatoleslami]

There is also the idea that an error is not necessarily an error in the sense that it is wrong but it is something that prevents the operation.  It could be that the far end is out of service or the network connection is down or the port is closed or the file permissions are set to what is not expected (once we missed a big revenue recognition opportunity at the end of the quarter because the file permissions were set to something we did not expect and we ran out of time during the maintenance window and had to back out the upgrade and wait for the next quarter).  In real life, they are real situations that must be handled.  Dave Cheney in his blog discusses this extensively.  In a way, thinking through the collection of events that prevent the happy path from proceeding must be thought through first.  

So, it pays to think of what could go wrong and handle it before anything else.

[Ian Lance Taylor]

On Thu, Jun 4, 2020 at 8:43 AM <lgo...@gmail.com> wrote:
>

> ?? Why not a cleaner syntax e.g. x = some_func () #{ } .. symbol # arbitrarily chosen

Besides what other people have said, it may be of interest to glance
through https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling
.

Ian

[Tom Limoncelli]

I assert that 80% of the annoyance that people feel is the number of
lines required to handle errors, not the syntax. Thus, a large
segment of the community would stop caring about this if we modified
gofmt, not the go language. Specifically, gofmt would simply format
short if's on one lie when possible.

OLD:

a, err := ioutil.ReadFile(patha)
if err != nil {
return err
}
b, err := ioutil.ReadFile(pathb)
if err != nil {
return err
}
c, err := ioutil.ReadFile(pathc)
if err != nil {
return fmt.Errorf("wrapped %v: %w", pathc, err)
}

NEW:

a, err := ioutil.ReadFile(patha)
if err != nil { return err }
b, err := ioutil.ReadFile(pathb)
if err != nil { return err }
c, err := ioutil.ReadFile(pathc)
if err != nil { return fmt.Errorf("wrapped %v: %w", pathc, err) }

This is half as many lines, thus makes it easier to fit on one
screenful of an editor, which is often a cognitive limit for a
developer.

I'm not saying that this solves the problem, but I bet it would reduce
the pressure to fix it.

Tom

--
Email: t...@whatexit.org Work: tlimo...@StackOverflow.com
Blog: http://EverythingSysadmin.com/

[Jan Mercl]

On Sun, Jun 14, 2020 at 5:25 PM Tom Limoncelli <t...@whatexit.org> wrote:
>
> On Thu, Jun 4, 2020 at 3:34 PM Ian Lance Taylor <ia...@golang.org> wrote:
> >
> > On Thu, Jun 4, 2020 at 8:43 AM <lgo...@gmail.com> wrote:
> > >
> > > ?? Why not a cleaner syntax e.g. x = some_func () #{ } .. symbol # arbitrarily chosen
> >
> > Besides what other people have said, it may be of interest to glance
> > through https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling
>
> I assert that 80% of the annoyance that people feel is the number of
> lines required to handle errors, not the syntax. Thus, a large
> segment of the community would stop caring about this if we modified
> gofmt, not the go language.

They possibly would stop. But Another part of Go programmer, who
prefer explicit and easily visible, distinct flow control constructs,
would probably start complaining. (I'm in that camp.)

IOW, it's not possible to please everyone. Status quo has the lowest
cost of any such changes.

[lgo...@gmail.com]

Amen Tom..  hard to believe that those who determine what Go syntax is, and is not, have yet to alter this uniquely awkward feature of the Go language.  

[Ian Lance Taylor]

https://golang.org/issue/38151

Ian

[lgo...@gmail.com]

https://golang.org/issue/38151   great news !... lets hope something finally gets resolved

FWIW, I modify my original proposal: replacing   #{.. .}  with   err {...}   

[Tom Limoncelli]

Great minds think alike!

[Randall O'Reilly]

I noticed a kind of circularity in the arguments around this issue. The simple "inline the if block" issue was created and rejected earlier: https://github.com/golang/go/issues/27135 -- in part because the central issue of error handling logic was supposed to be resolved by some other upcoming proposals. The newer issue: https://golang.org/issue/38151 has some additional elements that potentially detract from the basic gofmt-only version, and it has also been closed. There is also this closely related proposal which has not yet been rejected: https://github.com/golang/go/issues/37141

Overall there is certainly a consistent message from a substantial number of people that just compressing that high-frequency `if err != nil` logic down to 1 line *somehow* would solve most of the problem! But then there are those who argue in favor of the status quo.

Because consistency in formatting is an essential part of Go, it seems that this is fundamentally an "aesthetic" decision that must either be made by the core designers, or, perhaps, finding some way of performing a large-scale democratic voting process that would reasonably enable a large portion of the Go community to weigh in. It does seem that a lot of key decisions are being made on the basis of a very small sample of emoji votes in the issue tracker, so having a broader voting mechanism might be useful for informing the decision making process.. Anyone know how to write a good vote-collecting webserver in Go? :)

- Randy

> --
> 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/CAHVFxgmaFQoRaZd65FLbzZUWD4bKFqaWcqXQ3H7vm%3DNimi6B2g%40mail.gmail.com.

[lgo...@gmail.com]

"  It does seem that a lot of key decisions are being made on the basis of a very small sample of emoji votes in the issue tracker, so having a broader voting mechanism might be useful for informing the decision making process.. .."

At the very least, 'a broad voting mechanism'  would eliminate tons of repetitive posts regarding issues like ' if err != nil {..} '  and help Go developers focus of issues of major importance to Go users   

> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Jesper Louis Andersen]

On Thu, Jun 4, 2020 at 8:42 PM Michael Jones <michae...@gmail.com> wrote:

For that to work, it means that a function call either succeeds or fails. If it succeeds, then that's that. If it fails, then something special happens. Your "#" means "do this only if the function call failed." In that case itmust be true that functions have a notion of success and failure, that the cause of failure is invisibly returned and available as an extra "and here's why it failed" return value, and, new language concepts are required to access the value of the invisible return inside that "#{ ... }" block.

There are roughly two ways here:

errors are data flow

errors are control flow

They are, to a certain extent, equivalent since reflection/reification via monads allows a programmer to convert between these two notions, given the language has a way to embed monads somewhat easily.

The older I get, the more I want errors to be data flow in most cases. I don't think there is a good way around that much of programming has the penchant of failure. It has to be addressed in some way or the other. And if you have shared memory, there is no way around local handling of errors.