A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.
Declined Proposal: A built-in Go error check function, “try”
11–20 of 425 posts
Re: Declined Proposal: A built-in Go error check function, “try”
#12Great that they listened to the community
They listened to the part of the community that agrees with you.
I'm "community" and I would prefer to have `try()` than not to have. They didn't listen to me.
Re: Declined Proposal: A built-in Go error check function, “try”
#13With try, Go might have been a language I'd have enjoyed using. It's a shame. Right now, I see Go as being anti-abstraction and anti-cleverness, and I'd rather not work on codebases in which the language of choice is designed to deter creativity and encourage monotony. Heavy use of Go is a big negative when I evaluate potential projects to work on.
Re: Declined Proposal: A built-in Go error check function, “try”
#14Great that they listened to the community
The community is self-selected for the ability to tolerate Go-style error handling and the Go philosophy generally. It's not a philosophy for me.
Re: Declined Proposal: A built-in Go error check function, “try”
#15Kudos to the Go team for their process on this. IMHO it's worth reading Russ Cox's explanation of the problem area, including examples, and comparisons to other languages e.g. Rust and Swift. https://go.googlesource.com/proposal/+/master/design/go2draf...
"But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.
Exactly, and the error types have to match, or at least be convertible, or else it won't compile.
Seems either off-base or poorly worded.
Re: Declined Proposal: A built-in Go error check function, “try”
#16Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.
I didn't have particularly strong feelings towards this proposal (maybe just slightly against it) but it's probably important to note that people who are against it are generally much more vocal and make their voices are heard whereas those who like it just give it a thumbs up/tacit approval and keep it moving. Wish I knew how to accurately gauge the opinion of proposals from user communities.
Re: Declined Proposal: A built-in Go error check function, “try”
#17Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.
I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way.
It would also appear to be amenable to an automated tool that would convert to or from try-style.
Given that, why would people have strong feelings against? Because they think go needs something better, and if this passes, they'll never get it?
Re: Declined Proposal: A built-in Go error check function, “try”
#18Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.
[deleted]
Re: Declined Proposal: A built-in Go error check function, “try”
#19Kudos to the Go team for their process on this. IMHO it's worth reading Russ Cox's explanation of the problem area, including examples, and comparisons to other languages e.g. Rust and Swift. https://go.googlesource.com/proposal/+/master/design/go2draf...
"But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.
In the draft design, they give an example of special-case cleanup that would only execute only when an error occurs, not on the success path.
You can emulate this with a boolean flag in your RAII types in Rust or C++, that's set or cleared immediately before a successful return, and then doing conditional logic in your Drop/dtor. Or you could do a std::mem::forget before successful returns. But I guess they think this is an important enough case to dedicate syntax to it for ergonomic reasons, which Rust doesn't have - which is what I think they're getting at.
Re: Declined Proposal: A built-in Go error check function, “try”
#20Kudos to the Go team for their process on this. IMHO it's worth reading Russ Cox's explanation of the problem area, including examples, and comparisons to other languages e.g. Rust and Swift. https://go.googlesource.com/proposal/+/master/design/go2draf...
"But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.
`handle` would've allowed arbitrary code to execute in case of an error as opposed to "just" returning it back to the caller. That's what he's talking about.
For example, the example returns a custom wrapper around the original error with context that it was a copy operation with such-and-such source and destination. The equivalent in Rust using `failure::Fail::with_context` requires writing the `.with_context(|_| format!("copy: ..."))` on every expression that uses `?` (unless you happen to get lucky and all the inner errors are the same type, so that you can use combinators to combine them into a single `?`-able Result).
Edit: And to be clear, this is not limited to `failure::Fail`. Using your own `enum Error { Copy { source: PathBuf, destination: PathBuf, inner: Box }, ... }` still requires you to write a manual `.map_err(|err| Error::Copy { ... })` after every Result value that you intend to use `?` on.