For example, high-reliability code used in avionics software is said not to use exceptions, because it is worse for the airplane’s engines to shut down upon an error being detected than for them to keep running even if there is a malfunction or abnormality somewhere.
It’s important to note that contexts that high reliability contexts that don’t use exceptions don’t just ignore errors; they typically just have much more explicit error handling logic. And the “no exceptions” thing is really more language-dependent, since requiring all exceptions to be handled (like checked exceptions in old-school Java) would be similar in practice.
The “ignore errors” style of programming has been tried, and I think it’s been near-universally rejected. Once an error occurs, ignoring it and continuing usually doesn’t do what you want anyway, so crashing and getting enough info to fix it is much more helpful than doing something you don’t want. In cases where something really is optional, wrapping it in a try / catch is relatively easy, but having the language implicitly wrap every expression in a try / catch is really annoying.
It’s important to note that contexts that high reliability contexts that don’t use exceptions don’t just ignore errors; they typically just have much more explicit error handling logic. And the “no exceptions” thing is really more language-dependent, since requiring all exceptions to be handled (like checked exceptions in old-school Java) would be similar in practice.
The “ignore errors” style of programming has been tried, and I think it’s been near-universally rejected. Once an error occurs, ignoring it and continuing usually doesn’t do what you want anyway, so crashing and getting enough info to fix it is much more helpful than doing something you don’t want. In cases where something really is optional, wrapping it in a
try/catchis relatively easy, but having the language implicitly wrap every expression in atry/catchis really annoying.