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

391–400 of 425 posts

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

#391

Post by mikeschinkel »

steev wrote: post #309
icebraining wrote: post #292

Earlier quoted context omitted.

> `if err != nil { return err }` is actually bad Go code, and not often written by good Go programmers. Like the people who wrote the Go stdlib? Because that's filled with those - just look at the net/* packages.

Legitimate question: then what does good Go code that is written by good Go programmers do/look like? Wrap `err` in `errors.New("some function failed", err)`?

Recently the Go team introduced the xerrors package for improved error management: https://godoc.org/golang.org/x/xerrors

So using these functions is becoming part of what good Go programmers do.

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

#392

Post by mikeschinkel »

VMG wrote: post #289
sagichmal wrote: post #275

Earlier quoted context omitted.

One foundational principle of Go is that the sad path is at least as important, and maybe more important, than the happy path. The best Go programmers I know write the sad path of their programs first, and then backfill the happy-path logic. So: > you only need to write [error checking] when you actually have something meaningful to do. Although it's the subject of a lot of ridicule, `if err != nil { return err }` is…

> Errors in Go are, at a minimum, annotated with contextual information before being returned. What surprised me when I last wrote Go was that there was no out-of-the-box solution to adding a stack trace to the error.

JMTCW, but since I generally program Go in GoLand with the debugger, I have full access to the stack all the time so I have not found this to be a major concern. But YMMV.

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

#393

Post by mikeschinkel »

NateDad wrote: post #362
gigatexal wrote: post #341

Earlier quoted context omitted.

But five functions that return a value and an error would each have to run the if err != nil dance whereas with method chaining it's cleaner

not if each one can fail. What if call #1 and call #3 can return the same error.. how does the caller know which one failed? This is the same as wrapping a bunch of calls with a catch (Exception) ... you lose context of what failed and can't behave differently for different failures. All you can do is perform a generic "something went wrong" behavior.

Interestingly you _can_ implement method chaining to require a terminal method call i.e. err := GetFoo().SetBar(1).SetBaz(2).Run() and then each chained method would set an error property in the object and if err!=nil then do nothing but return the object, and then the last method could return the error value.

That said, I am not a huge fan of fluent interfaces. I much prefer passing in a struct as an "args" parameter, in most case (but not all.)

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

#394

Post by mikeschinkel »

kerng wrote: post #193
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.

Copy/paste is very error prone. Golang code is full of it. I see lots of similarities between Visual Basic and Golang, incl. the passionate communities behind the languages.

Curious, do you see other communities that are not passionate about their languages?

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

#395

Post by mikeschinkel »

pjmlp wrote: post #373
kerng wrote: post #193

Earlier quoted context omitted.

Copy/paste is very error prone. Golang code is full of it. I see lots of similarities between Visual Basic and Golang, incl. the passionate communities behind the languages.

With the difference that Visual Basic is an academic language full of needless features from Go's community point of view.

Visual Basic is hardly academic; they is a tremendous amount of line-of-business code that has been written in VB over the past 25 years.

But yeah, Go dev do not see VB's features as being "features."

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

#396

Post by mikeschinkel »

kazinator wrote: post #119
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…

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…

You do not have to be precise in Go either, and you don't have to know all the faults. All you have to know if where a return value that implements the interface `error` is not nil.

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

#397

Post by ngrilly »

billylindeman wrote: post #350
vegancap wrote: post #345

Quite rightly, too! It's annoying for beginners, but you quickly see the utility in the if err != nil {} approach, or 'sad path' approach after a few years of using Go in production. You learn to love it! To be honest, there's very little I'd add to the Go language, if anything. It's very unique that most Go developers share that view of a language. With Javascript, for example, I can't wait for 'new stuff', I think…

Agreed. When I first started writing go I thought "Wtf is this caveman language" And now years later I couldn't imagine going back to using exceptions. The non-linearity of exceptions creates such a cognitive load of picking up unfamiliar code, and this is where go really shines. I can dive into almost any go codebase and get a lay of the land very quickly. On another note, I've been enjoying rust's approach with Res…

> On another note, I've been enjoying rust's approach with Result / the ? operator.

For the record, the `try` proposal which was just declined, is almost equivalent to the `try!` macro in Rust, which was the "testbed" for the `?` operator.

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

#398

Post by ngrilly »

apta wrote: post #218
alexbanks wrote: post #209

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I use golang at an employer. error handling in golang is verbose, error prone, distracting, and difficult to make sense of when there is actually an error (composing). I've seen on several occasions now errors being mishandled (either dropped by accident, or by overwriting already existing error variables in the same…

Have you contributed to the discussion about `try` in the GitHub issue tracker?

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

#399

Post by ngrilly »

qtplatypus wrote: post #268
alexbanks wrote: post #209

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

I am a full time developer in go. I feel the lack of good error handling every time I write a function call and then have to use the same if statement to check its result.

Have you contributed to the discussion about `try` in the GitHub issue tracker?

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

#400

Post by ngrilly »

break_r wrote: post #337
alexbanks wrote: post #209

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I am a full-time Go developer. Error handling in Go is miserable. `try` would have made it slightly less miserable.

Have you contributed to the discussion about `try` in the GitHub issue tracker?
Post reply on HN