4 ms·

One reason I like Golang is that errors are on your face. Sure, it's annoying, but it really helps robustness. (I like Rust, C, C++ etc. as well.)

• 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.
  • badrequest 3y ago
    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.
  • mariusor 3y ago
    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.
  • mighmi 3y ago
    No, it isn't necessary. Most go projects implement error handling functions, so you only have single error lines: Handle(err)