Declined Proposal: A built-in Go error check function, “try” • Hacker News Board

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

#151

Post by ummonk » Wed, Jul 17, 2019, 2:03 AM UTC

closeparen wrote: post #96

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.

Yes, this is exactly what I've observed in practice with Go.

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

#152

Post by thomascgalvin » Wed, Jul 17, 2019, 2:03 AM UTC

EdwardDiego wrote: post #137

tempsolution wrote: post #55

Earlier quoted context omitted.

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…

My most hated checked exception is the IOException Jackson throws when parsing JSON I can guarantee to be valid JSON. I could live with a runtime exception, or perhaps an API that differentiates parsing "potentially not-parseable JSON" and "JSON I can vouch for".

I usually end up writing a bunch of utility methods for stuff like this. Typically it's called something like `parseQuietly`, and it just Pokemons any exceptions.

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

#153

Post by UK-AL » Wed, Jul 17, 2019, 2:12 AM UTC

unscaled wrote: post #58

switchbak wrote: post #25

Earlier quoted context omitted.

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

Java-the-language was designed to be anti-clever, but a decade later, most code written in it ended up being the epitome of hyper-cleverness. Lack of abstractions (a.k.a "cleverness") on the language level, pushed developers to abstraction on the code level, often based on reflection and supported by XML files and (later) annotations. In retrospect, by avoiding cleverness in Java, we ended up with multiple incompatib…

Java style design patterns are often just a crutch for the lack of abstraction in the language.

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

#154

Post by Thaxll » Wed, Jul 17, 2019, 2:12 AM UTC

KirinDave wrote: post #120

natefinch wrote: post #98

Earlier quoted context omitted.

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

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

#155

Post by djur » Wed, Jul 17, 2019, 2:12 AM UTC

patientplatypus wrote: post #123

mevile wrote: post #84

Earlier quoted context omitted.

I don't see how a switch statement helps you avoid checking for errors when methods you use return errors, and a lot of methods return errors.

You can pass functions to functions ( https://play.golang.org/p/XNMtrDUDS0 ). So you can do (sans syntax): ErrorCheckerFunc(fn myParams -> MyFunc(myParams), "message") ErrorCheckerFunc(fn myParams2 -> MyFunc2(myParams2), "message2") etc... and then the actual function: ErrorCheckerFunc(fn myFunc, message){ returnVal, returnError = myFunc(); switchError: case error is foo: print error case error is bar: log error prin…

I'm not clear on what exactly you're trying to represent here, but it looks like something that wouldn't work with Go's type system. ErrorCheckerFunc would need to always have the same return type and accept a function with the same type signature.

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

#156

Post by bmurphy1976 » Wed, Jul 17, 2019, 2:12 AM UTC

gridlockd wrote: post #124

pcwalton wrote: post #78

I suspected this was coming, and it's unfortunate. If Go had implemented try, then in a year everyone would be happy using it and the controversy would have died down. I've seen this happen before. Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

The controversy may have died down, but the impact on code written would have been permanent. There's a lot of value to there being "one way to do things", even when it's not the best way from any particular point of view. Go holds this principle higher than most other languages and I think that should be either embraced, or one should look elsewhere - and I'm saying that as someone who "looked elsewhere".

I think you make a reasonable point that is worthy of discussion. Unfortunately there's a group of people on this thread that are downvoting comments such as yours instead of discussing them. I'd like to see reasoned responses to your comment, i.e. tell us why you are wrong instead of the downvote brigading.

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

#157

Post by KirinDave » Wed, Jul 17, 2019, 2:12 AM UTC

wybiral wrote: post #117

pcwalton wrote: post #106

Earlier quoted context omitted.

> 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('¯\_(ツ)_/¯')

... I could do this with Golang too, couldn't I?

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

#158

Post by ghostpepper » Wed, Jul 17, 2019, 2:14 AM UTC

KirinDave wrote: post #102

tempsolution wrote: post #55

Earlier quoted context omitted.

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…

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

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

#159

Post by geodel » Wed, Jul 17, 2019, 2:14 AM UTC

KirinDave wrote: post #102

tempsolution wrote: post #55

Earlier quoted context omitted.

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…

> 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?"

Of course you can. But it would be hilarious considering Java Module system (Jigsaw) which took decade in making still does not support versioning. People are left to use bloated crap like Maven or Gradle. But since these products are called "enterprise grade" developers are not supposed to call them crap that they really are.

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

#160

Post by bmurphy1976 » Wed, Jul 17, 2019, 2:15 AM UTC

abtinf wrote: post #135

baby wrote: post #66

Earlier quoted context omitted.

I spent years as a consultant reading codebases in different languages. I can tell you that Golang win hands down for clarity of code and structure of projects (and perhaps second after Rust in terms of security. If only it had options ...) So yeah, it's actually quite fast to dig in a Golang codebase. You notice that as a normal user when you find it faster to read the standard library vs reading the doc, or when yo…

Go is the only language where I look at the standard library source instead of google whenever I run into an ambiguity in the docs. I think there are three reasons for this. First, the docs link to the actual line in source, so it’s just a click away and available in the exact context I need it. Second, I know I’ll be able to understand it: there are usually very few dependencies, so I can usually get all the context…

I agree, and if others disagree they should comment and explain why instead of downvoting you.

One of Go's major selling points (for me anyway) was a solid standard library written mostly in conventional Go style. It's a great example of how Go code should be written, and a wonderful learning tool for the language.

It also makes participating in the community easier because that's one less thing you have to learn in order to contribute.