4 ms·

I mean, you're not wrong, It's just strings (usually) instead of ints. It's pretty bad, but it turns out that exceptions and inverting my entire program to pas

• kaba0 2y ago
  > It's pretty bad, but it turns out that exceptions and inverting my entire program to pass into a Result's flatmap chain are even worse Based on what? Exceptions do the sensible thing at all times: auto-bubbling up (no random swallowing), contain info about its origin, and a handler can be specified as tightly or widely as necessary. It’s objectively superior to grepping for an error message, or straight up not doing anything which go is especially prone to do, as after a time all the if errs become just visual noise.
  • Kamq 2y ago
    > Based on what? My experience using all three. > no random swallowing We have not been in the same codebases, apparently. The number of times I've come across (I'm paraphrasing): try { // some stuff that can fail // bonus points if there's a comment explaining why it can't error in practice } catch (Exception e) {} Is hilarious. Especially when it happens in library code. As verbose as `if err != nil { return nil, err }` is, the fact that it gets banged out so much means people default to it, and I find myself less likely to get into a weird partially initialized state in go than I have been in other languages. > It’s objectively superior to grepping for an error message Then use `errors.Is`?