Hacker News Reader

Comment by nepthar | Hacker News Reader

Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling.

I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!

View on HN

It really depends on what you're developing.

If it's some random web backend, it's often fine to just let the error propagate as a 5xx. Many error cases wouldn't have a better solution anyway, and all that's breaking is a single page or resource load. (Of course on the frontend it might be nicer to show some kind of an error than just e.g. having frontend functionality silently fail.)

If it's a desktop application and you're crashing the entire application because wifi happened to drop or whenever there's anything your happy path didn't predict, that's going to be bad.

If it's some kind of an embedded thing and you're crashing an entire device because you didn't bother to handle cases that are outside of the happy path but entirely possible, I only hope it's not something important you're developing.

I'm fine with doing this on purpose, but without a system like checked exceptions, you do it without even really realizing you're doing it. Checked exceptions point out the errors and then let you decide whether it's something you should handle or let it crash. It makes for more stable software.

The number of exceptional errors one can reasonably handle is so small to be insignificant. Aborting the current operation (which could be just one task or the whole application) is the most common result. Abort and log. Unchecked exceptions make that easy. Checked exceptions make that long and tedious and add nothing.

What and where you can handle exceptions has nothing to do with where the exception is thrown. Handlers only exist at key points in the application at the start of operations where you can skip, abort, or retry.

its only an illusion of stability. so many things can go wrong outside of exceptions and all it does is add mandatory lines of code (probably rethrowing as a runtime exception) to every single consumer. It pollutes everything it touches.

I didn't know Java apps were so much more stable than C# ones.

If you actually let it crash that's fine, but a lot of people just toss a catch (Exception ex) in there because they don't know what exceptions will happen and don't want errors that aren't actually a big deal to bring the system down. But the issue with catching everything, even if you log before continuing, is that the process may be in a bad state and you're just continuing with it like that. I got to see a couple database tables get absolutely mangled by a process that had an exception that was caught and logged. That was a pain to clean up since doing nothing more than restoring a backup would have lost the entire day's worth of business operations in that system.

This is what I like about Go and other more recent languages: Especially when networking or other IO is involved, things will go wrong. These languages don't try to circumvent this reality but instead embrace it by treating errors as very-first-class citizens. My error handling tends to be more thoughtful in those languages than in, say, Java.

In practice there is a lot of paths that you don't want to "crash" on, but try the next thing etc.

Don't model those as Exceptions, because they are not exceptional. They are control flow.

You can't have your pie and eat it too. Some callers will want a Result, some will want to panic. A Result can be panicked on very easily, but handling control flow with exceptions and try/catch has been proven a huge failure.

That idea just leads to confusion, as the line between exceptional or not will always be blurry, and depend on how it is called, the specific input data, your hardware state, etc.

you basically end up needing to write your api twice.

> I like coding for the happy path and letting exceptional states crash.

Of course everyone like coding like this. No one likes to code error handling code.

Just like no one likes to code tests and documentations.

It turns out not every important thing is joyful.

Reply on news.ycombinator.com