> If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software

> If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software for nuclear plants), isn't it? That depends entirely on the use case. I certainly don't want my MCAD/ECAD software crashing because someone introduced a rare bug in the CSV parser that trips over some unrelated library files - I'm perfectly capable of learning how to get it to a safe state for a restart without losing any data. Anyone who uses massive software package like that for their livelihood learns to work around bugs that cause inconsistent state. #8 is important because there needs to be a generic way to pass errors up through component hierarchies that may not look like the call stack. In many architectures, for example, the exception in an event handler has to get handled at the root of the event loop, not the parent component. That exception handler has to be smart enough to bubble that exception up through parent components.