Thank God!
God codes in C, and uses three space tabs.
I'd definitely be interested in knowing what His take on error handling is.
Declined Proposal: A built-in Go error check function, “try”
21–30 of 425 posts
Re: Declined Proposal: A built-in Go error check function, “try”
#22Perfect timing. Started mucking around with the Go compiler recently to implement my own error handling.
https://pbs.twimg.com/media/D_ojiEqUYAAhmrH.png
edit: s/%s/%d/ but you get it.
Re: Declined Proposal: A built-in Go error check function, “try”
#23Great 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.
"Listened to" is colloquial for "engaged with". They engaged with people who represented the `try()` option and declined to implement it.
It is impossible to implement every proposal their ears listened to so obviously that's not what listened means.
Re: Declined Proposal: A built-in Go error check function, “try”
#24With 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.
Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language
Re: Declined Proposal: A built-in Go error check function, “try”
#25With 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.
I think that's quite on purpose - a lot of folks seem to look down on 'clever' code. I think at its extreme we can almost all agree that hyper-clever code is a bad thing. I think we just differ on where that threshold starts for every day code.
Apparently (early) Java was designed in much the same way, just to a lesser degree.
I'm not a fan of languages specifically designed to limit me from expressing myself. Then again, I work on small/disciplined teams, where this tends to work out pretty well.
Re: Declined Proposal: A built-in Go error check function, “try”
#26Good 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”
#27Earlier quoted context omitted.
God codes in C, and uses three space tabs.
I'd definitely be interested in knowing what His take on error handling is.
It's undefined and implementation specific.
Or maybe she took the approach Linus did with git and just let it crap out and start clean next big bang.
Re: Declined Proposal: A built-in Go error check function, “try”
#28Re: Declined Proposal: A built-in Go error check function, “try”
#29Great 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.
They didn't listen to the community. It was not a democratically driven decision. They gathered feedback from the community, weighed it in, discussed it and took a decision considering all aspects. It's not like they listened to whatever had the most votes on Github. At least I'd like to believe they didn't.
Re: Declined Proposal: A built-in Go error check function, “try”
#30Earlier quoted context omitted.
"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 th…
> execute only when an error occurs
You can use the match construct for that, and the Result type comes with some utility methods that make it easier to clarify your desired semantics in many cases. The page complains that the "match" syntax is clunky, but I'm not that sure how 'handle' is supposed to be better.