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.

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

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.