Hacker News new | past | comments | ask | show | jobs | submit login

go’s error handling patterns, while lacking every established feature that makes it ergonomic, is baffling.

Embarrassing that developers are still forgetting nil pointer checks in 2024.




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 propagating the error up. The actual logic get drowned out.


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.


> 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/Prelu...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: