Hacker News Reader

Comment by Noughmad | Hacker News Reader

In most languages, the top words are self/this and function/def. On the other hand, in Go, the most common word is "err", and "if err != nil" are three of the top four words. I really wonder how big part of the code in Go is just propagating errors.

View on HN

One day, maybe half a decade from now, Rob Pike will wake up from a nightmare and suddenly realise they got this one wrong. Maybe it'll occur at the same time as the generics one.

There are some was to make error handling much less annoying in go. Since error is just an interface it's pretty easy to make monadic constructs that can carry the error information and let you write pipelined code. IMHO it makes the code much cleaner and easier to read, but a lot of golang enthusiasts haven't really adopted the idea because it's quite different from the established idioms around error handling. Hard-core gophers love them some verbose and stupidly explicit code; but I'm hoping that as the language gets adoption in the wider community the voice of reason will win here.

Interfaces require casting and hurt performance, though.

You could come up with `Either` types, but due to the lack of generic structs you'd have to have a whole lot of those.

Interestingly, Rust has basically the same error handling idiom, but verbosity is considerably reduced by the '?' operator (previously the try! macro).

When I was coding in Go, i would have loved that feature. The mind-numbing error checking in go is hugely annoying.

> When I was coding in Go, i would have loved that feature. The mind-numbing error checking in go is hugely annoying.

Ugh. Yes. I really want to love go. No, I really love go. But this is so annoying.

Could you link to some instructions?

I've been working on putting together an in-depth series of blog posts about it. I'm presenting on the topic of better error handing in go at the Agile Tech Conference this year, and I'd like to start getting everything in order soon- I'll probably post here on HN.

In the short term I have a really rudimentary library I've put up here: https://github.com/asteris-llc/gofpher and a presentation on it here https://github.com/rebeccaskinner/presentations/tree/master/... (should build with pdflatex, I need to get an actual pdf built soon)

Rob Pike has a blog post that looks at a similar, although ideologically different, approach to doing it: https://blog.golang.org/errors-are-values

I think the latter is more go-ish, although also less generic than the monadic approach- it's also more in keeping with the ideology of go, but in practice I still never see it being used much in production code.

Same with many node apps. Every other statement is:

    if (err !== null) {
      return callback(err);
    }

With es2015+ this is no longer the case, it's back to good old try/catch statements if using async/await, and .catch(...) if using promises.

I was thinking about forking the language just so I could add a Maybe monad.

I now typically deal with this via a Must() function that takes to values and return the non-err value or panics if there was an err.

That means you can call it like con := Must(db.Connect(...)).(db.Connection)

This is not super-conventional, but some of the standard library uses panics in a similar way.

I think as long as panics don't cross library boundaries you're fine. And panics can cross library functions if the function is called MustConnect(). (Which means it'd be neat to have a pre-processor that generated MustX from X if it wasn't already there...)

To be honest, part of the reason for this is that in Go, 'self' is any name you see fit in the particular context, otherwise it may still be self.

This made me smile as well. While I'm now used to it, I have troubles saying there's nothing wrong in having `err` a more common word than `if` :)

Letting errors surface is a good thing.

having 3 out of 4 lines in your codebase dedicated to letting errors surface is a bad thing.

3 out of 4 most common words are related to error handling. How does that imply 75% lines are error handling?

    err := someOperation(args...)
    if err != nil {
         return err
    }

that's 4 lines, 3 of them are error handling

"err". Because "error" is too hard to type, right?

Well, `error` is the type, and `err` is the most common variable name. It's not so unusual, just convention!

Also, it cuts the characters you have to type and read in halve, while not being obtuse.

That's an odd thing to complain about.

No, because error variables have extremely limited scope and the length of a variable name should be proportional to its scope.

Heh, I always use longer name variables for broader scope somewhat naturally, but only after reading your comment realized that.

    if theErrorReturnedByThePreviousFunction != nil {
         panic(theErrorReturnedByThePreviousFunction)
    }

A real brogrammer can write COBOL in any language.

I figure it's probably proportional to its importance and difficulty of understanding, as a longer more descriptive name aids in understanding, but things with broader scope tend to be more important.

From which it follows that you should use the most terse names possible, in order to make it harder to write too-long functions.

(I am only half trolling).

I wonder the same thing about "elif" in Python. It's two extra characters to make it the more pleasant, readable "elseif". I don't understand why dropping those letters was felt necessary.

A lot of older parts in Python inherit the naming style common in C, which always seems to me they have OCD to shorten everything, e.g. ls for list, mk for make. Newer Python parts are more “healthy” in this regard. But this also results in some wierd inconsistencies like mkdir vs makedirs.

Reply on news.ycombinator.com