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

111–120 of 425 posts

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

#111

Post by Arnavion »

MaulingMonkey wrote: post #80
0815test wrote: post #30

Earlier quoted context omitted.

> 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.

As Arnavion points out, handle handles multiple error cases. That said, I'm not convinced it's better in practice . For some comparison points - here's how I'd write the Go CopyFile in Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio... Or, if we want to keep a more 1:1 direct mapping to the Go code: https://play.rust-lang.org/?version=stable&mode=debug&editio... Caveats with the "1:1" mapping: 1) I…

>1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type.

In all the real code bases I've worked on, there are multiple disparate types of errors that nevertheless have the same context.

Example: A function that takes in a path and parses a config file at that path fails if it can't open the file or if the file is malformed. The file can be malformed because indentation is wrong, because there's a string where there should be an integer, or because a required field is missing. All of these are different error types.

So a single `std::io::Error` is not possible, and erasing them into a `Box` or wrapping them in a custom (context-containing) type nevertheless requires writing a `.map_err` per each Result value.

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

#112

Post by KirinDave »

stcredzero wrote: post #92
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 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.

> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things.

I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open.

> 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.

I'm used to languages where this generally isn't the case, but sure. Why twist the knife in the wound though?

> Glossing over error handling in golang can feel bad exactly when it should.

When you capture but fail to check an errval and an untraceable default value starts rattling around inside your code causing unexpected behavior? It's like an NPE but worse because it won't immediately trap. It's more like a double free.

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

#113

Post by FireBeyond »

libria wrote: post #23
kjksf wrote: post #12

Earlier quoted context omitted.

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.

And they also "fast tracked" the decline "ahead of schedule".

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

#114

Post by pcwalton »

matthewbauer wrote: post #105
pcwalton wrote: post #82

Earlier quoted context omitted.

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.

This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?

There's go vet. But it's inconsistent with the Go warnings-are-errors philosophy. Ignoring the return value of os.Mkdir() is far more likely to be a bug than an unused import is.

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

#115

Post by gridlockd »

tempsolution wrote: post #55
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…

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…

> Littering your code with try-catch is what makes exceptions infeasible for error handling.

I honestly don't see the big difference between littering your code with if/else blocks versus littering them with try/catch blocks. Can you elaborate?

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

#116

Post by bmurphy1976 »

inlined wrote: post #41
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…

> errors being values Though with generics we could have the error values be less invasive. Learning the Scala mindset was eye opening. For e.g. the design patterns of an Optional[T]’s primary code flow are the same as a Try[T,E]. With common transformation idioms, you learn to recognize code patterns the same way one might recognize data structures. It’s no less magical and it simplifies greatly.

But it doesn't simplify, it just moves the complexity around. That's not necessarily bad, you get better safety guarantees as a result but you also spend more time fighting the compiler and locked in design space trying to get a model that works (and even MORE time is spent if you want it to be readable and something that other people can grok quickly).

I don't see this as an either/or situation. There's a continuum between do whatever the hell you want C and rigorously defined Idris code. Picking a spot on that line involves many trade-offs and everybody has to choose what's right for their situation. That means Go approach is sometimes superior to the Scala approach for a certain class of problems in certain domains.

Edit: don't downvote me, tell me how I'm wrong.

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

#117

Post by wybiral »

pcwalton wrote: post #106
jchw wrote: post #94

Earlier quoted context omitted.

>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 se…

> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting…

> any code search reveals that "if err != nil { return err }" is everywhere

Code searches in languages with exceptions tend to wrap the tryblocks around massive portions of code instead of the individual function calls to the point that you have a top level doing:

  try:
      ...program here...
  except:
      print('¯\_(ツ)_/¯')

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

#119

Post by kazinator »

natefinch wrote: post #98
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…

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…

Did you know where every page fault would happen, and manually check every memory access and fix the situation?

You didn't have to because there is an precise, robust non-checked exception handling system which takes care of that: the hardware catches the situation, dispatches a handler in the operating system which fixes it and re-starts your program at the original machine instruction to try the memory access again.

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

#120

Post by KirinDave »

natefinch wrote: post #98
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…

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…

I guess then I have to ask, why would try() make that worse?

Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced.

On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be confident I can just use an error handling strategy. The only complexities appear, as with everyone else, when we have asynchronous code.

So I don't mean to disagree with your feelings, but they're sure not mine and they're part of why I don't use Golang. I was excited about try() because it at least addressed the most tedious part.

Post reply on HN