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

171–180 of 425 posts

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

#171

Post by weberc2 »

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…

I like your points about diagnostics. I definitely feel this—it seems like one of Go’s weakest points. That said, Go is still one of the best tools available for building software today.

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

#172

Post by pbreit »

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…

If it matters to anyone, this novice finds “if” easier to understand than “try”.

Very refreshing for novice to agree on expert on a topic.

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

#173

Post by _hardwaregeek »

Thaxll wrote: post #154
KirinDave wrote: post #120

Earlier quoted context omitted.

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

How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.

It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.

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

#174

Post by UK-AL »

bmurphy1976 wrote: post #125
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.

And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics. Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical por…

In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.

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

#175

Post by joeblubaugh »

poweroftrue wrote: post #168

Just try writing three Go programs with error handling, then, try other languages! I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line. Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid. The simplest example is adding a default-path whenever I'm rea…

Reminds me very much of “Simple, Elegant, Wrong”

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

#176

Post by bmurphy1976 »

UK-AL wrote: post #174
bmurphy1976 wrote: post #125

Earlier quoted context omitted.

And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics. Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical por…

In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.

It's not just that though, GC is also a big part of the equation. I stopped manually managing memory 20 years ago. I'm not interested in going back to that.

I get that certain aspects of Rust make that easier (and certainly safer) but I'm not working in a domain where the performance gains of ditching GC matter.

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

#177

Post by KirinDave »

ghostpepper wrote: post #158
KirinDave wrote: post #102

Earlier quoted context omitted.

> It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. Should I compare it to "Golang Dependency Hell Claimed My Project?" > 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 actually have been a viable design. Why? That's not…

> Should I compare it to "Golang Dependency Hell Claimed My Project?" As someone just learning Go, what is Golang Dependency Hell?

It's not a problem you have to deal with but those of us from the world before bundled vendoring list projects because of Go's creators not having sympathy with people not living in a single global monorepo universe and most of its audience not having the discipline to vendor stuff by hand.

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

#178

Post by KirinDave »

baby wrote: post #70
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…

The bad ergonomics? Golang is an excellent language.

I don't think it qualifies for that name.

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

#179

Post by Thaxll »

_hardwaregeek wrote: post #173
Thaxll wrote: post #154

Earlier quoted context omitted.

How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.

It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.

I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something.

It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _

https://golang.org/doc/effective_go.html#blank

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

#180

Post by meruru »

wybiral wrote: post #51
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…

> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that…

pg wrote a bunch of really good essays about Java vs Python vs Lisp and how those were perceived by programmers. I always remember them when I see Go being compared to Java while still being liked by Hackers. I wonder what he would write about this phenomenon.
Post reply on HN