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

11–20 of 127 posts

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

#11

Post by est31 »

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…

> On the other hand, it might be a first step onto a slippery slope that ends with exceptions.

Rust originally had a try! macro just like go and is slowly sliding down that very slope. Let's just say there is a split in the community about whether an exception like outside syntax is a good idea or not. Some like the idea, some don't like it. It yields in threads like this one: https://github.com/rust-lang/rfcs/pull/2426

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

#13

Post by lunixbochs »

I implemented try() in Go five years ago with an AST preprocessor and used it in real projects, it was pretty nice: https://github.com/lunixbochs/og

Here are some examples of me using it in error-check-heavy functions: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

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

#14

Post by axaxs »

marcrosoft wrote: post #9

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.

Agreed. This is the hill I'll die on. Boring error handling is what I specifically love about Go...

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

#15

Post by tedunangst »

codr7 wrote: post #10

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...

The error can't go through a function that doesn't return an error, unlike exceptions. Also, you have to ask for this. Reversing the default is a big difference.

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

#16

Post by [deleted] »

tedunangst wrote: post #15
codr7 wrote: post #10

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...

The error can't go through a function that doesn't return an error, unlike exceptions. Also, you have to ask for this. Reversing the default is a big difference.

[deleted]

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

#17

Post by arcticbull »

codr7 wrote: post #10

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...

Exceptions are the opposite of a goto statement, basically a 'comes-from' statement. They violate the principal of least surprise in every way possible -- you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. They often result in memory leaks in languages like C++ due to lack of destructor invocation.

try() errors can only propagate to the caller. As such, stack unwinding is clear, no memory issues arise, performance is good and locality of error is preserved. Surprise is minimized.

While it may look similar, it's pretty markedly different in important ways.

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

#18

Post by umurgdk »

I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may return from the caller. And there is a reason why golang doesn't have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects' code.

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

#19

Post by X6S1x6Okd1st »

lunixbochs wrote: post #13

I implemented try() in Go five years ago with an AST preprocessor and used it in real projects, it was pretty nice: https://github.com/lunixbochs/og Here are some examples of me using it in error-check-heavy functions: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

I wrote something similar but of lower quality about 5 years ago as well

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

#20

Post by cpuguy83 »

Error handling is, to me, the most important thing when writing any code.

Promoting "if err != nil { return }" even more by giving it a keyword seems like a dangerous road to walk down.

Are we proposing solutions to make developers not have to type "if err != nil" or are we looking at how we can help developers handle errors better and be more productive?

I honestly don't have anything to offer as far as ideas for changes to the language, but I really hope we think through the long-term ramifications of these changes.

Post reply on HN