[blindseer]

I like that errors are in your face too, but with the caveat that only when they matter. And in Go, the lazy thing will result is a bad time. You can always bet on people being lazy.

Like take a look at this pattern:

    err := db.Get(&latLong, "SELECT lat, long FROM cities WHERE name = $1", name)
    if err == nil {
     return latLong, nil
    }

    latLong, err = fetchLatLong(name)
    if err != nil {
     return nil, err
    }

    err = insertCity(db, name, *latLong)
    if err != nil {
     return nil, err
    }

Is it really necessary to have the error handling explicit in this case? Go through any of your go code. I find this kind of error handling is 90% of the error handling I write.

[mariusor]

Only one of the calls in the block is an actual irrecoverable error that you should propagate up to the parent caller.

If you just append if err != nil blocks everywhere without reasoning about the context you're probably doing it wrong.

[badrequest]

If those calls can cause errors, then yes, it's necessary to handle them. Maybe you're content to have a contextless stack trace printed whenever things fail, but I like a little order.

[mighmi]

No, it isn't necessary. Most go projects implement error handling functions, so you only have single error lines:

Handle(err)