Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: A built-in Go error check function, try

github.com

Post reply on HN
Print view View original

1–10 of 127 posts

Re: Proposal: A built-in Go error check function, try

#2

Post by alexhutcheson »

It looks like it’s basically a less hacky version of what the RETURN_IF_ERROR and ASSIGN_OR_RETURN macros[1] do in C++.

From experience, those work pretty well. That approach eliminates a lot of the boilerplate bookkeeping code, while still making it explicitly obvious to the reader that a given function call can fail.

This seems nice, and I would definitely use it.

[1] https://github.com/protocolbuffers/protobuf/blob/master/src/...

Re: Proposal: A built-in Go error check function, try

#4

Post by hliyan »

So basically they're proposing:

  f, err := os.Open(filename)
  if err != nil {
    return …, err  // zero values for other results, if any
  }
can be simplified to

  f := try(os.Open(filename))
This makes a lot of sense, but I'm of two minds. On one hand, it makes things much cleaner. On the other hand, it might be a first step onto a slippery slope that ends with exceptions.

A lot of others chiming in with different ideas on the original ticket: https://github.com/golang/go/issues/32437

Re: Proposal: A built-in Go error check function, try

#6

Post by jerf »

hliyan wrote: post #4

So basically they're proposing: f, err := os.Open(filename) if err != nil { return …, err // zero values for other results, if any } can be simplified to f := try(os.Open(filename)) This makes a lot of sense, but I'm of two minds. On one hand, it makes things much cleaner. On the other hand, it might be a first step onto a slippery slope that ends with exceptions. A lot of others chiming in with different ideas on th…

After chewing on this for a while, I've come to the conclusion that the thing exceptions does wrong (or if that is too controversial, substitute "most dangerously") is that it disconnects handling the error from the scope that generated it. It's the way exceptions so easily fly up the stack into code that can't understand them because it is too distant in context that is the problem. Neither this proposal, nor any other I saw, would change that. I wouldn't even call this "a step in the direction of exceptions"; it's a neutral move. Everything is still occurring within the same scope, it's just getting spelled differently.

Interestingly, this means that while pervasive use of "if err != nil { return err }" is technically very similar to exceptions when used everywhere, it can still have a different semantic meaning to a human reading the source.

Re: Proposal: A built-in Go error check function, try

#7

Post by dickeytk »

is it just me or does the word "try" seem to imply the opposite here? To me saying "try" is like saying "attempt to run this" like we have in a try/catch block. I feel like something like "expect" would more directly explain what this does.

Great functionality though. I'd be very happy to see this included no matter what it's named.

EDIT: This is answered in the FAQ section after I read further. Apparently it's because "try" is already a keyword. I still don't like it, but I get it.

Re: Proposal: A built-in Go error check function, try

#9

Post by marcrosoft »

Please for the love of god no.

Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either eliminate the need for the error or handle it like you would any other value.

Stop trying to make go work like every other language.

Re: Proposal: A built-in Go error check function, try

#10

Post by codr7 »

I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere (except where you forgot and the error is dropped silently)?

Here is my proposal: add restarts [0] as a complement to manual propagation.

[0] https://github.com/codr7/g-fu/blob/master/v1/doc/typical_res...

Post reply on HN