I don't quite get #8. An exception should be handled where we expect it, depending on a reason for the exception. 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?
> 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.
So the actual challenge should be a bit better specced. The flight booking example, but some configurations are invalid and the validation can only be calculated after the form is submitted. How should the error be handled?
