Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Declined Proposal: A built-in Go error check function, “try”

github.com

Post reply on HN
Print view View original

91–100 of 425 posts

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

#91

Post by pcwalton »

jchw wrote: post #61
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

>So long as we can all agree that it feels super bad, I guess this is fine. Actually, I don't think everyone agrees it feels super bad. I personally like having all of my error handling be explicit, painfully explicit even. >approaches the Java world back with checked exceptions where principle trumped ergonomics. I also have to disagree here. To me, checked exceptions are the worst of both worlds. Here you have addi…

> Worse, everything that happens in a try block is 'flattened.' Not only does this mean you may need many try blocks, sometimes it can even be difficult to take individual statements and put them in one try block.

Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics.

> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them.

Go doesn't make it harder to accidentally not check errors. If you call a function that only returns an error, such as os.Mkdir(), then the compiler will not warn you when you forget to handle the error.

> Language ergonomics are complicated, but the benefits of Go's approach are hard to deny.

I don't really see any benefit to Go's approach over exceptions or result types. If making it obvious that errors are handled is important, there's a solution for that that's much more elegant than if-err-nil blocks everywhere. It's precisely the solution that the Go community just rejected.

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

#92

Post by stcredzero »

KirinDave wrote: post #45
wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

So long as we can all agree that it feels super bad, I guess this is fine

Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. Glossing over error handling in golang can feel bad exactly when it should.

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

#93

Post by gjs278 »

pcwalton wrote: post #82
unixsheikh wrote: post #63

This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software. If it ain't brok…

Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

you still had to think about it when you decided to drop it to the floor by putting the _ saying "I acknowledge there was an error, but I don't care"

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

#94

Post by jchw »

pcwalton wrote: post #91
jchw wrote: post #61

Earlier quoted context omitted.

>So long as we can all agree that it feels super bad, I guess this is fine. Actually, I don't think everyone agrees it feels super bad. I personally like having all of my error handling be explicit, painfully explicit even. >approaches the Java world back with checked exceptions where principle trumped ergonomics. I also have to disagree here. To me, checked exceptions are the worst of both worlds. Here you have addi…

> Worse, everything that happens in a try block is 'flattened.' Not only does this mean you may need many try blocks, sometimes it can even be difficult to take individual statements and put them in one try block. Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semant…

>Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics.

Go does not suffer from this issue at all. I am not talking about flattening from the call hierarchy, I am talking about flattening the try scope itself.

(In case it isn’t obvious: in Go you’d be forced to separate two error checks. But it results in still less cumbersome code, since you only need scoping for the error handling portions.)

But forgetting that, because passing errors down in Go is explicit, it is actually customary to use error wrapping to add context as an error is propagated, which does allow for more precise error handling actually.

>Go doesn't make it harder to accidentally not check errors. If you call a function that only returns an error, such as os.Mkdir(), then the compiler will not warn you when you forget to handle the error.

Go vet will do that. It is a good 'first step' to configure when setting up your CI/CD (many will do it by default.) Go vet's 'unusedresult' checker does this.

>I don't really see any benefit to Go's approach over exceptions or result types.

It is a simpler language than Java. You get most of the benefits of checked exceptions without all of the calories from exceptions.

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

#95

Post by gjs278 »

kjksf wrote: post #12
drivebyops wrote: post #5

Great 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 shouldn't listen to you because you just tried to add a new way of error handling that has been proven to lead to unreadable messes

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

#96

Post by closeparen »

unixsheikh wrote: post #63

This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software. If it ain't brok…

Typing “if err != nil { return nil, err }” a million times is not thought.

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

#97

Post by nine_k »

randomdata wrote: post #75
AnimalMuppet wrote: post #17

Earlier quoted context omitted.

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…

> Because they think go needs something better, and if this passes, they'll never get it? More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to fo…

Unfortunately, they saddled the language with the lack of generics, which has a nonzero cost, too.

Worse yet, Go community may develop, or already has, a taste to the lack of genetics. When a really really good proposal comes along, and is implemented, it may produce a Python 2/3 rift with the existing code bases, or not be accepted at all because of this.

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

#98

Post by natefinch »

KirinDave wrote: post #45
wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other languages.

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

#99

Post by viraptor »

wybiral wrote: post #62
KirinDave wrote: post #56

Earlier quoted context omitted.

I don't think folks are on 2.7 because they love it. I think they're there because it's difficult and expensive to migrate Python code.

There were multiple reasons based on my experience. New people were still using 2.7 tutorials because there was way more information out there than for 3. And package managers in Linux systems took a long time to change. But the asyncio example is probably a better example of a fundamental program design change that's causing weird fracturing and incompatible library designs. Trying to use non-async from an async fra…

I don't believe that python 2/3 change has much to do with sync/async issues. In python 2 we had twisted which was its own async universe. The sync and async worlds are disconnected in pretty much every language, but it's mostly a non-issue. You just don't mix them and it doesn't become a mess.
Post reply on HN