3 ms·

The error handling is one of the worst parts of Go for me. Every call that can fail ends up being followed by 3 lines of error handling even if it's just propag

• danudey 2y ago
  I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. That said, I discovered that Go has the ability to basically encapsulate one error inside of another with a message; for example, if you get an err because your HTTP call returned a 404, you can pass that up and say "Unable to contact login server: <404 error here>". But then the caller takes that error and says "Could not authenticate user: <login error here>", and _their_ caller returns "Could not complete upload: <authentication error here>" and you end up with a four-line string of breadcrumbs that is ostensibly useful but not very readable. Python's `raise from` produces a much more readable output since it amounts to much more than just a bunch of strings that force you to follow the stack yourself to figure out where the error was.
  • instig007 2y ago
    > I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. This is called (>>=)[0], but most of the industry is ignorant enough to call it impractical and non-pragmatic (as opposed to their pragmatic `if err`) [0] https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelude.html#v:-62--62--61- https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...