Hacker News Reader

Comment by rhizome31 | Hacker News Reader

Strongly agree with your second point, too many times I had to figure out issues caused by code trying to handle errors but actually hiding them and making it so much harder to debug. The typical antipattern: catching SomeErrorType just to log "error of that type occurred", thus hiding the associated error message and the stacktrace. Even worse: trying to catch every error types.

Don't catch errors unless doing something actually useful with them. Even then, it's often a good idea to re-raise.

View on HN

I also believe people throw way too many exceptions. You should be able to be explicit about the outcome of an error case, and not just throw exceptions in a panic.

So alongside swallowed exceptions is throwing exceptions in scenarios that were entirely recoverable, and I think in both scenarios devs just don't understand their program enough and are choosing to panic, or ignore the problem.

I think people often throw exceptions rather than write the code that handles the situation more gracefully. If you knew it could happen, then is it really an exceptional circumstance?

I think it's impossible to come up with a good rule of thumb for error handling. Sometimes catch-and-log is what you want. Sometimes catch-and-reraise is what you want. Sometimes let-it-fail is what you want. I really cannot come up with a good argument that one of these is the better default. Languages should force us to consider which failure mode we want for every function that can possibly result in error.

The most egregious thing to me is the fact that most languages let any function throw any error it wants without requiring that be documented or part of the type system or anything.

I try to make sure that the failure happens as close to the cause as possible. For instance, validate input when it's supplied rather than when it's used.

100% agree. “Error” is as big and ambiguous as “success”. What should a successful function return? True / false? An object? A URI? Nothing?

There is no rule of thumb because the scenarios are too varied and context matters.

I’d like to add a corollary to this

- Sometimes what’s best for the system isn’t what’s best for your job

Fail fast is a good ethic but all to often I’ve encountered applications that are only to happy to limp along for the sake of optics. If that’s the prevailing sentiment where you work I’d recommend against violating it off your own bat.

Reply on news.ycombinator.com