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

161–170 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#161

Post by kitd »

lolinder wrote: post #12
dlisboa wrote: post #11

Earlier quoted context omitted.

One thing I don't get (and would honestly appreciate if was explained to me) is how the Result monad differs significantly from Go's error handling, other than being a "true" monad. Most Rust code I see does things like (from the docs): let greeting_file_result = File::open("hello.txt"); let greeting_file = match greeting_file_result { Ok(file) => file, Err(error) => // handle err }; It isn't much different from: fil…

The killer feature of Rust's Result isn't actually the monad itself, it's the ? operator. Being able to concisely say "if there's an error, bail out by returning it" gets you pretty close to exception-level convenience with just a bit more explicit syntax showing where an error might come from.

I've not used Rust. Do you get to add context at the point of bailing?

Re: Gopher Wrangling: Effective error handling in Go

#162

Post by tgv »

preseinger wrote: post #28
incompatible wrote: post #7

"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Println statements.

fmt.Printf failures are un-actionable, so there's no reason to handle them

That's what the parent comment means, I think.

Re: Gopher Wrangling: Effective error handling in Go

#163

Post by kitd »

za3faran wrote: post #135
tail_exchange wrote: post #108

Earlier quoted context omitted.

The programmer needs to be aware that they will need to provide enough context in case of a failure. One thing I see a lot in Go examples is this pattern: body, err := readFile(fileName) if err != nil { return "", err } If the error returned by readFile is just "not found", it would indeed be very vague. This is still poor error handling, in my opinion, since a lot of the context is lost. Yes, they are "handling" the…

You basically end up reinventing stack traces, with all the possible ways context can be missed. This summarizes the language quite well.

IME, it's stack traces that miss all the context. So an error occurred 20 levels down? What was it doing? With what?

Re: Gopher Wrangling: Effective error handling in Go

#164

Post by kaba0 »

mtzet wrote: post #154
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 agree that go and rust have different areas, but that was less clear when they were getting started. Back then go was trying to figure out what it meant by 'systems programming language' and rust had a similar threading model. Another point is that they do share similarities, which might we might now just describe as being 'modern': They're generally procedual -- you organize your code into modules (not classes) wi…

> I agree that go and rust have different areas, but that was less clear when they were getting started

That I agree with.

But Go is anything but modern on a language front. It shares almost nothing with Rust, which actually has a modern type system (from ML/Haskell).

Even if we disagree about exceptions (I do like them as they do the correct thing most of the time, while they don’t mask errors, but include a proper stacktrace), go’s error handling is just catastrophic, being an update from c which is even worse is not a positive.

Re: Gopher Wrangling: Effective error handling in Go

#165

Post by kaba0 »

konart wrote: post #136
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…

In my personal opinion it's a great language to solve problems _I_ have to deal with in course of my work. Can I solve them with Java? Sure. Difference is go does not have the complexity you can find in Java and quite opinionated. So you don't have to spend as much time working with the language inself and can focus on getting the job done. Go is not as expressive and some other languages and does not have the same a…

Java is absolutely not a complex language. The “enterprise java” style is an unfortunate one that can actually be traced back to C++, but it is not a necessity at all, and due to the sheer size of the java ecosystem you will find plenty of examples of a more barebones approach — also supported by the language developers.

I fail to see why I would go with go over java, besides.. perhaps some CLI app? With Graal even that can be implemented in Java.

Re: Gopher Wrangling: Effective error handling in Go

#166

Post by hibbelig »

mtzet wrote: post #154
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 agree that go and rust have different areas, but that was less clear when they were getting started. Back then go was trying to figure out what it meant by 'systems programming language' and rust had a similar threading model. Another point is that they do share similarities, which might we might now just describe as being 'modern': They're generally procedual -- you organize your code into modules (not classes) wi…

> I really dislike exceptions because there's no documentation for how a function can fail. For this reason I prefer go style errors, which are an improvement on the C error story. Yes it has warts, but it's 80% good enough.

I’m not a go developer. How does go document how a function can fail?

A Java developer can use checked exceptions so that some information is in the signature. For unchecked exceptions the documentation must explain.

I guess in Go the type of the error return value provides some information but the rest needs to be filled in by the documentation, just like the Java checked exceptions case.

Re: Gopher Wrangling: Effective error handling in Go

#167

Post by kaba0 »

philosopher1234 wrote: post #130
kaba0 wrote: post #105

Earlier quoted context omitted.

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…

Thanks, you are likely correct.

Re: Gopher Wrangling: Effective error handling in Go

#168

Post by philozzzozzz »

kinghajj wrote: post #50
philozzzozzz wrote: post #39

Earlier quoted context omitted.

Where is the error handling in your Rust code?

The `?` at the end of the Rust example expands into the equivalent of the Go `if err != nil` idiom.

You are illustrating the point beautifully.

Re: Gopher Wrangling: Effective error handling in Go

#169

Post by comex »

BobbyJo wrote: post #14
incompatible wrote: post #7

"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Println statements.

That seems like the kind of thing you'd want to wrap and panic on rather than ignore. If fmt.Print doesn't work, you should probably just kill the process.

That has the downside that if the user pipes your program’s standard output to, say, `head`, then once `head` is done reading the first few lines and exits, the program will blow up and probably print a message to standard error that clutters the user’s terminal (where they were expecting to see the first few lines of output).

Though, continuing to spend time generating more output that goes nowhere may not be particularly useful either, depending on what the program does.

Still I think ignoring errors writing to stdout is better as a general default. If nothing else, it’s the most common behavior and is thus more likely to fit the user’s expectations.

Re: Gopher Wrangling: Effective error handling in Go

#170

Post by throwawaymaths »

za3faran wrote: post #145
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'm strongly convinced that the google brand name gave it a big push. Its predecessor (Limbo if I recall correctly) went nowhere. It did bring uncolored async to the mainstream, but as in typical golang fashion, it was very verbose and error prone. Java learned the right lessons and I'm quite excited to see their structured concurrency approach. No need to pass channels and contexts everywhere to manually manage hier…

> It did bring uncolored async to the mainstream

I believe that uncolored async (Erlang) precedes colored async (python)

Correction: c# was the first language with colored aaync, still way after Erlang

Post reply on HN