4 ms·
FWIW, I wrote a short response here: https://twitter.com/_rsc/status/1146128393542492160 https://twitter.com/_rsc/status/1146128393542492160 I want to flag esp
by rsc 7y ago
FWIW, I wrote a short response here:
https://twitter.com/_rsc/status/1146128393542492160 https://twitter.com/_rsc/status/1146128393542492160
I want to flag especially that there is not, nor has there ever been, a plan to "push this through".
People consistently say error handling is problematic for them in Go. Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors. We would like to see if we can find a way to make it both less work and more correct. Maybe we can, maybe we can't. The process is slow and needs to backtrack out of formerly-promising dead ends, and that's OK.
There's a very large amount of conversation right now around try, and that's good. Like I said in the tweets, community-wide discussions like this one are open source at its best.
- tmaly 7y agoJust curious, why a twitter thread response and not a blog post?
- pfarnsworth 7y agoI think "try" is a terrible name, because it overloads try/catch which is very common usage these days but it's nothing like that. It's basically a error checking macro, so give it a new name.
- Sphax 7y agoRust had the try! macro before which is similar, the name is fine I think.
- willtim 7y agoWhy not allow call-by-name parameters to functions? That would enable library authors to build whatever error handling conveniences they wanted. This feature dates all the way back to ALGOL-60.
- Cthulhu_ 7y agoI think you're answering your own question there: > That would enable library authors to build whatever error handling conveniences they wanted What I want from a language - especially if it's, like Go, aimed at really big project - is for it to be opinionated and narrowed in options. That's Bill Kennedy's point as well, they're adding a language level feature so now there's one more way to do a very common thing. And when there's multiple ways to do something, they will all get used. "But what about conventions and code reviews?", you might ask; that's cognitive overload that, if there was only one way, would never be a thing. I mean another feature of Go is that it enforces a certain standard (with tooling and formatters), so that as a development team you should never have to waste time and energy on discussing or arguing about formatting. I'm not against changing how errors are handled now, as long as they're standardized and the One Way to do things.
- willtim 7y agoI respect this position, but we must also recognise that it makes Go less of a general purpose language (as is often claimed) and more a domain-specific language (with the domain being systems/network programming).
- cassianoleal 7y ago> Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors. Care to elaborate on both points, or direct me somewhere I can learn more about these opinions? Thanks!