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

Gopher Wrangling: Effective error handling in Go

stephenn.com

Post reply on HN
Print view View original

121–130 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#121

Post by notTooFarGone »

janosd wrote: post #116

Go's error handling is a horrible mess: 1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling. 2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using. 3.…

Calling a linter thirdparty in Go is really disingenuous. Like you install go in your favourite IDE and it's batteries included. It's part of the standard set.

Re: Gopher Wrangling: Effective error handling in Go

#122

Post by andrewjf »

preseinger wrote: post #27
tester457 wrote: post #9

Go error "handling" blocks don't seem like error handling, when it's 3+ visual polluting LOC that just return the error up the call stack, occasionally with context like tip #4 of the blogpost. I've tried to like go's verbose error handling (follow the “happy path”) but the error handling signal to noise ratio is skewed in a way that makes developing in go feel slow and boring.

the idea that error handling "pollutes" code is a misunderstanding which go addresses the "sad path" of error handling is equally as important as the "happy path"

Then it would seem that it's required for the compiler to make sure you're consuming the return values (happy and sad) correctly by having the compiler enforce access to them, which go completely punts.

Re: Gopher Wrangling: Effective error handling in Go

#123

Post by kodah »

andrewjf wrote: post #101
kaba0 wrote: post #91

Could someone explain why is Go so hyped? In my personal opinion it is just not a good language, and I think many judge it based on some false basis that it is somehow “close to the hardware” because it produces a binary. Like, the amount of time it is put next to Rust when the two have almost nothing in common.. It is very verbose, yet Java is the one that is called that, often by Gophers, which is much more concise…

I feel like a lot, if not all, has to do with the Google backing. Back when Go was announced, the company had _a lot_ of goodwill, and were envied by anyone doing software engineering. So, pretty much anything they did had an immediate following and base of engineers willing to blindly adopt whatever they did.

Hard disagree. Go provided a simple answer for asynchronousness in 2012 and was used to build Kubernetes. Because it was used to build Kubernetes a lot of patterns and influence developed very quickly, which made the language very agreeable to anyone writing APIs, systems tooling, or daemons. The portability and cross compilation were also developer favorites as they have downline effects in how simple it is to produce your final product in a CI pipeline.

To me, there were a lot of obvious reasons to choose Go in a corporate environment where my success is graded on my ability to deliver and the quality of what I deliver.

For every popular Google project you read about there are many flops, including ones they appear to develop in spite of.

Re: Gopher Wrangling: Effective error handling in Go

#124

Post by randomdata »

awused wrote: post #117
randomdata wrote: post #109

Earlier quoted context omitted.

> This entire discussion is about the type system and how it interacts with the language. No. The discussion opened to say that Result is better than the pattern used in Go. In other words, dependent state is better than independent state. I said that dependent state puts the producer in control, while independent state puts the consumer in control and that there are pluses and minuses to each approach, with neither…

>The discussion opened to say that Result is better than the pattern used in Go You are trying to paint a false dichotomy between Rust's Result and Go's (T, error). In reality the dichotomy is between sum types (which Result is a very simple case of) and languages without sum types, of which Go is one of a very small set. The key difference is that Result is available as an option in Rust/Haskell/Ocaml/etc, and I'm f…

The thing is, that very false dichotomy was painted before my time. I refuted it. And you have spent your time claiming to refute what I said, albeit using random tangents that don't pertain to anything, which must mean that you too want to paint the false dichotomy? That or you didn't bother to read anything and just hope and pray that if you say type system enough times someone will bite even though it is the most boring topic imaginable and, as such, nobody ever will.

Re: Gopher Wrangling: Effective error handling in Go

#125

Post by andrewjf »

preseinger wrote: post #71
za3faran wrote: post #51

Earlier quoted context omitted.

How does it address it? By making it painstakingly verbose (not to mention error prone) to deal with errors? Not referring to you personally, but I've heard that sentiment several times now, and I have not seen anything to back it up (as with several other golang claims).

given a function fn that can fail, it will return a result and an error e.g. result, error = fn(...) calling this function should yield to the caller two possibilities, somehow: a success value _or_ a failure error the important thing is that in both cases, the control flow is visible in the source code as written result, error = fn(...) if there was an error, ... if it was successful, ... when an expression fails, y…

Yeah, but you're still relying on the programmer to do it correctly which is nothing but false hope.

Re: Gopher Wrangling: Effective error handling in Go

#126

Post by mirekrusin »

konart wrote: post #113
mirekrusin wrote: post #112

Earlier quoted context omitted.

You can shoot yourself in the foot with null pointers.

You can find a gun to shoot yourself in the foot in any language.

Well, it's million dollar one though. It has been solved in many languages. It gives quite uneasy feeling that high percentage of your LoCs can be potentially affected, it doesn't come from some contrived edge case code, it's everywhere.

Re: Gopher Wrangling: Effective error handling in Go

#127

Post by cwalv »

preseinger wrote: post #30
eddythompson80 wrote: post #5

There is a lot that I like about Go. Error handling is not one of them. On one hand, I appreciate the simplicity of it all. Nothing special about an error, it’s just part of how you do everything else. But on the other hand, there is something clearly special about an error. It’s something 100% of go users have to deal with in almost every single function call. There is something clearly special about it. These grass…

if you write a line of code that can fail, then you should deal with the possibility of that line failing there, directly, in-line _how_ you deal with that failure is a separate question but it's critical that every fallible expression explicitly and visibly demonstrates the possibility of failure this is in no way an "error handling mess" -- on the contrary, it is basically the only way to produce robust and reliabl…

In my experience, the vast majority of the time the best (or only) way to correctly deal with the error is to propagate it up the stack. Making this optional (having to explicitly check return values) doesn't make it more likely to be done.

Re: Gopher Wrangling: Effective error handling in Go

#128

Post by awused »

randomdata wrote: post #124
awused wrote: post #117

Earlier quoted context omitted.

>The discussion opened to say that Result is better than the pattern used in Go You are trying to paint a false dichotomy between Rust's Result and Go's (T, error). In reality the dichotomy is between sum types (which Result is a very simple case of) and languages without sum types, of which Go is one of a very small set. The key difference is that Result is available as an option in Rust/Haskell/Ocaml/etc, and I'm f…

The thing is, that very false dichotomy was painted before my time. I refuted it. And you have spent your time claiming to refute what I said, albeit using random tangents that don't pertain to anything, which must mean that you too want to paint the false dichotomy? That or you didn't bother to read anything and just hope and pray that if you say type system enough times someone will bite even though it is the most…

>The thing is, the false dichotomy was painted before my time. I refuted it.

No, it wasn't and you didn't. Result is one option among many in Rust which covers the common case with concise syntax, where (T, error) is the only option in Go. I am free to return a Success, PartialSucceess, Failure in Rust/Java/C++/Ocaml/Typescript. I think you're operating on some profound misunderstandings about Rust, Haskell, Ocaml, Java, Typescript, C++, and even C. I don't think you're open to trying Rust, but maybe you'd be open to playing with std::variant in C++ or manually tagging unions in C, to see what those languages can do that Go cannot. Try writing a C++ function that returns std::variant between T, std:::tuple, and Error. That's only 3 cases, which Go cannot do.

Re: Gopher Wrangling: Effective error handling in Go

#129

Post by kinghajj »

kaba0 wrote: post #91

Could someone explain why is Go so hyped? In my personal opinion it is just not a good language, and I think many judge it based on some false basis that it is somehow “close to the hardware” because it produces a binary. Like, the amount of time it is put next to Rust when the two have almost nothing in common.. It is very verbose, yet Java is the one that is called that, often by Gophers, which is much more concise…

https://en.wikipedia.org/wiki/Worse_is_better

Go is a language made by Googlers, so its design helps with Google problems. And many of Google's problems are ones of scale.

* Go is straightforward to read. Any reasonably-competent college graduate should have little trouble understanding it and be able to become productive quickly.

* Go compiles into completely static binaries. You don't have issues like "oops, the build system runs CentOS 7 but we're deploying it to Ubuntu 18.04 and their libc's aren't compatible." With containers, you can copy many Go programs into `FROM scratch` images and they will work fine, greatly reducing the attack surface area.

I used to dislike for Go for similar reasons to you and others, but after using it for a few years at $employer, I've come to appreciate its merits. Sure, it can be a bit annoying to write

    if err != nil {
        return err
    }
again and again at first, but I just type 3yy7jp to yank+paste it as needed. You could also configure some editors to detect when you type `if err` and generate it automatically. It's also not uncommon for editors to fold the lines down into a single line.

Re: Gopher Wrangling: Effective error handling in Go

#130

Post by philosopher1234 »

kaba0 wrote: post #105
philosopher1234 wrote: post #102

Earlier quoted context omitted.

I think this claim is too reductionistic to go anywhere. There is no single thing that can explain go’s success. There are hundreds of small differences in the language (and tooling, which arguably is more important). Most people are not going to care enough (or have the time) to enumerate every single difference between go and Java, and why they prefer the trade off go makes. I use Java professionally, and go where…

Then let me ask instead: why does Go hit the HN front page each day? I would say Rust used to be/is similarly hyped, but it is sort of understandable there, as it is built on a novel idea and fits a previously unoccupied space. This is not true of Go, and we could just as well see just as many D, Java, C#, Haskell, OCaml posts, yet they combined are not as frequent “visitors”.

I think there is something that advocates/users of Go see in it that they don't feel has been understood by its detractors. And on the flip side, I think the detractors are not very interested in understanding what is good about Go, instead it seems more like a nuisance to be swatted away. I think this creates a great deal of tension between the two, and leads to massive blowup threads. So long as issues (like error handling) persist where these groups cant understand each other, i think the same arguments will repeat.
Post reply on HN