Hacker News Reader

Maybe the issue is that "exception" is a really confusing name. Go has the keyword "panic" for errors that stop the current flow and unfold the stack, that makes it clear that you shouldn't use them for anything else than exceptional situations, and they can be "recovered" if they have to be handled explicitely.

https://blog.golang.org/defer-panic-and-recover

View on HN

From my (admittedly limited) experience, Go has the worst story for error handling, where functions end up repeatedly checking for error return conditions from called functions.

It feels trapped between "We don't want exceptions" without going full "Result<T> or Maybe<T>" functional style that might be more typical of something like elixir.

But I didn't try Go for long and that itself was years ago, so perhaps modern Go has better paradigms.

I'm just mentioning the naming, not the general approach to error handling. Panic are roughly similar to what an "exceptional exception" is (stop control flow, unfold stack until being handled), but the naming is slightly better IMHO.

I personally like Go's approach, but that's not for everybody (I'm also quite fond of the monadic approach though).

Nope. Error handling in Go is still tedious.

Reply on news.ycombinator.com