| I think exceptions are bad not because of the principle but because code is written by humans. We use Go in our company and every intern learning it complains about the error handling at first. Then they write a bunch of programs and those basically never crash. I had and intern write a somewhat complex service mangling large amounts of Geodata which was his first go service ever. That thing ran for years without crashing once (it died due to an hardware problem). The reason is simple: Golangs stupidly verbose error handling forces you to constantly think about the unhappy paths. Every function is littered with error handling and it makes you aware of possible problems and rigorously forces you to not forget them. Exceptions are the opposite: people do whatever and have someone else deal with the fallout later.
This leads to people not thinking about errors and then someone using catch(all)-> doNothing kind of "solutions". On top of that exception based error handling is what i call transparent (like in invisible). So you can write a function using some other function without being aware the there could be exceptions thrown (unless your Language uses checked exceptions like Java). One can not possibly know every detail and remember the constantly. So if something goes wrong, you end up with super deep stack traces at unexpected places. This is unlike Go code where the error usually is handled at the earliest point possible with (hopefully) reason and contingency. |
> Exceptions are the opposite: people do whatever and have someone else deal with the fallout later. This leads to people not thinking about errors and then someone using catch(all)-> doNothing kind of "solutions".
Ha! One shop that I worked at early in my career considered such null checks (in .NET, a language with a VM that would throw instead of crashing if you attempted a null dereference) the height of software craftsmanship. They bragged about remembering to do it at critical junctures and made fun of other teams that didn't do it.
Brilliant! No exception, no problem! This was great - except it was slowly discovered that features were silently broken for months on end until users directly complained about them. Then things were still great because the manager declared that no error messages showed up anywhere, so nobody got scared, so nothing was wrong.They were right in a sense: the same manager had hand-built a SOAP-based logging solution with a bespoke UI that required us to explicitly log everything instead of just dumping to the regular sink and having an aggregator consume it for later viewing in Splunk or otherwise. We only got to see stack traces by RDPing into the specific server and looking for them - we'd never have seen these exceptions regardless!