It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the s

It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the success case. In my experience with the medium sized projects I've been closely responsible for (in the hundreds of thousands of lines ballpark), we were interested in doing a really good job in both the exception and the error result cases, because the misbehavior scenario is a real issue, and followed all the good practices in the modern developer's backpack. In the end, exception-rich code just turned out obviously hard to get right, no matter how much we _wanted_ to get it right, because the program is allowed to jump out of arbitrary stack frames that the developer was conveniently taught to not handle errors on, because.. hey! the "default behavior"! After getting involved in these experiments, I started paying more attention to how people can possibly be happy with exception-rich logic that behaves like that. My empiric observation is that the lack of proper error handling turns out to have a relatively low impact for lots of projects. Crashed or misbehaved? Whatever.. file a bug.