On Thursday, July 4, 2019 at 10:55:50 AM UTC+2, Slawomir Pryczek wrote:
>
> going to turn code into unreadable, fragmented mess
>
Do you really think that replacing:
f, err := os.Open("file.txt")
if err != nil {
return err
}
By:
f := try(os.Open("file.txt"))
Will "turn code into unreadable, fragmented mess"? Isn't it a bit of an
overstatement?
> My point is it doesn't fix anything, it doesn't provide any clear
> benefit... it's an attempt to fix something which works great and is
> clearly not broken.
>
try fixes error handling verbosity, while keeping the language grammar and
semantics unchanged. I respect that error handling verbosity is not an
issue for you, but when you wrote that it is "clearly not broken" you're
denying it can be an issue for other Go developers.
> So why complicate the language with a new keyword which has really no
> purpose.
>
As mentioned in the proposal, try is not a new keyword, it's just a new
built-in function.
Maybe adding a warning about unhandled errors to VET would be better idea
> (which would probably be complicated to do properly, but at least it'll
> have some real, positive effect on code quality).
>
The compiler and vet already report unhandled errors.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3153b982-7b8b-45ac-9a33-29f661b468da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
