Hacker News Reader

Comment by arwhatever | Hacker News Reader

It's worth noting also that the benefit of doing this is to avoid the difficult-to-reason-about, goto-like behavior that exception throwing and catching necessitates. I have yet to experience a team which handles that very well at all; it usually turns into a mess.

View on HN

I feel like this statement is often used and just as often wrong.

It's not about avoiding the goto like behavior. It's about making you to know it exists and forcing you to handle it.

Rathet than throwing 5 calls deep, doing nothing until you empty your call stack, you must explicitly say "I know I'm part of a system that may error" at each step along the way.

In my experience (most) exceptions also cause people to forget about their own failure state, i.e. "always on the “happy path”", so they leave a mess behind when something they call throws an exception. Often they don't haven't handled failure state even when their own code throws an exception.

As much as people like to hate Java's checked exceptions, this is one thing I feel they really help with. They force you to think about the failure cases at least enough to either declare that you percolate them up, or handle them.

I've been writing a lot of Kotlin recently, and Kotlin doesn't have checked exceptions. This has led me to start migrating away from exceptions entirely because without checked exceptions it gets too hard to track what can fail, and how. I've been switching to an approach like the author's of using an `Either` (actually `Validated` from arrow-kt -- a special purpose `Either`) to have failures in my return values. I just have to be careful when calling library code to immediately translate exceptions into return values, but the entire stack in my own code has no exceptions (aside from unrecoverable errors).

Reply on news.ycombinator.com