5 ms·
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
by blindseer 3y ago
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 3y agoOnly 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.
- mighmi 3y agoNo, it isn't necessary. Most go projects implement error handling functions, so you only have single error lines: Handle(err)
- badrequest 3y agoIf 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.