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

221–230 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#221

Post by rob74 »

nprateem wrote: post #184
nbraxf100 wrote: post #176

Earlier quoted context omitted.

The error handling is second nature to anyone who has done C or Unix programming. It just feels dirty not to check for an an error. This is one part I like about Go.

Which rules out the majority of people who learnt to code in the last 25 years (many unis have taught java since 2000ish)

Because people don't ever learn more about programming than what they were taught in university? If this is true, I'm a bit afraid about the career perspectives of these students, and wouldn't really want to be on a team with them...

Re: Gopher Wrangling: Effective error handling in Go

#222

Post by preseinger »

kaba0 wrote: post #216
adezxc wrote: post #203

Earlier quoted context omitted.

It is easier to know that lowercase is package-specific, uppercase is exported, than knowing which field is private/public by default. Go reserved keywords: break, default, func, interface, select, case, defer, go, map, struct, chan, else, goto, package, switch, const, fallthrough, if, range, type, continue, for, import, return, var Java reserved keywords: abstract, continue, for, new, switch, assert, default, goto*,…

You have conveniently left out types from go’s list.. with those removed it is hardly longer, and as has been shown (case-sensitive identifiers), not all language complexity lives within keywords.

the parent's point was to compare the set of reserved keywords in the two languages

types do not enter the discussion

Re: Gopher Wrangling: Effective error handling in Go

#223

Post by preseinger »

kaba0 wrote: post #164
mtzet wrote: post #154

Earlier quoted context omitted.

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…

go's error handling is not catastrophic, it is very good

Re: Gopher Wrangling: Effective error handling in Go

#224

Post by earthboundkid »

lolinder wrote: post #80
earthboundkid wrote: post #75

Earlier quoted context omitted.

Kubernetes is a huge project and not idiomatically written, so it would be shocking if it didn’t exhibit everything that can go wrong with Go. CockroachDB is a better example.

This is a No True Scotsman fallacy. "No REAL Go code fails to handle errors." OP demonstrated that failing to handle errors does in fact happen in the wild, while in Rust the compiler enforces that you must handle them. The question is whether this difference between the systems has practical implications, and it seems it does. The existence of community idioms that help avoid the problem doesn't change the fact that…

The question is whether the problem happens a lot or rarely. I’m saying Kubernetes is a bad example of the problem happening a lot because it’s a ton of code (which yes, is poorly written), and CockroachDB is a good example of it happening a lot because there is less code and it’s at a higher quality.

Re: Gopher Wrangling: Effective error handling in Go

#225

Post by bvrmn »

preseinger wrote: post #37
lolinder wrote: post #12

Earlier quoted context omitted.

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.

you don't want exception-style "convenience", that's the whole point you want to be able to read code and see a single control flow ? subverts that core requirement

And what the point to make `if err {return err}` in most of cases? I've read a lot of code and error handling logic almost never in caller location.

Re: Gopher Wrangling: Effective error handling in Go

#226

Post by MrBuddyCasino »

skarlso wrote: post #120

This feels like it has been written by someone who recently started using the language, considering that the code in many places simply doesn't compile and has syntax errors or logical errors in it. Many people coming into Go as a new language immediately start bickering about how they want their previous language features in Go rather than accept what Go has to offer and at least try to understand it. This is the eq…

> CreateMyFriggingObjectFactorySingletonBuilderFactoryBuilders

2005 called, they want their Enterprise Java™ jokes back.

Re: Gopher Wrangling: Effective error handling in Go

#227

Post by nprateem »

rob74 wrote: post #221
nprateem wrote: post #184

Earlier quoted context omitted.

Which rules out the majority of people who learnt to code in the last 25 years (many unis have taught java since 2000ish)

Because people don't ever learn more about programming than what they were taught in university? If this is true, I'm a bit afraid about the career perspectives of these students, and wouldn't really want to be on a team with them...

Only a minority will be sufficiently sadistic to learn C when better alternatives exist. So yes, the above excludes the majority.

Re: Gopher Wrangling: Effective error handling in Go

#228

Post by meling »

arez wrote: post #198
kaba0 wrote: post #193

Earlier quoted context omitted.

An if err with some random one-liner in the err part is not error handling. You can’t reasonably handle an error condition on a local basis, that’s why exceptions (especially checked ones) are superior. They do the correct thing — either bubble up if it doesn’t make sense to handle them in place, or have them in as broad of a scope as it makes sense with try-catches. Oh and they store the stacktrace, so when an excep…

yes, that's exactly how I also think about Go's error handling. It was always praised the in the early days but it becomes more and more obvious that it's not a good way of handling errors, let alone reading code full of error returns and if err

I see this argument a lot, but error handling is also code that you probably want to read. Especially if you are debugging a problem. My experience is that exposing the error handling logic makes this easier. But I also like John Ousterhout’s suggestion to define errors out of existence where possible (A Philosophy of Software Design). But that requires more thinking than some developers like to deal with.

Re: Gopher Wrangling: Effective error handling in Go

#229

Post by preseinger »

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.

stack traces are tools for developers, error messages are tools for users

users should not see stack traces

Re: Gopher Wrangling: Effective error handling in Go

#230

Post by preseinger »

AlexCoventry wrote: post #31
marcus_holmes wrote: post #22

Surprised that the "always wrap your errors" rule isn't in there. It's been the rule in the last few Go teams I've been in.

We moved away from wrapping them recently for performance reasons.

what programs are you writing where error wrapping represents a performance cost that's worth avoiding???
Post reply on HN