How about a physical analogy? Your boss instructs you to organize and file some boxes of paperwork and tells you do exactly as you're told and not to bother her until the job is done for any reason. During the process of filing, you:

 - Discover the office hallway is blocked off for construction work. You stand there starving and dehydrated for a week until the work is complete and the hallway is reopened. 

 - Discover the file room door is locked, so you pile all the files up in front of the door. 

 - Realize the index that tells you where each file goes is missing, so you make up your own new filing scheme entirely different than the exiting one.

 - Realize the labels on the files are in a writing system you don't understand, so you guess wildly at how to alphabetize them.

 - Notice one of the boxes contains an active bomb, but you know you're not supposed to disturb your boss, so you file the bomb and don't tell anyone.

 - Notice the office is now exploded and on fire, and keep delivering files into the flames until the fire department drags you out of the building.

When you meet your boss outside, you let her know you finished the filing job and there were just a few problems you noticed along the way. That's what  happens when you don't crash early: at every point in the process, the environment was unsuitable for you to do the work, but you kept on going in the hope it would work out instead of stopping immediately. 


----------


So what does that mean for programming? If there's a problem (usually delivered to you in the form of an exception or a failed assertion check), you need to immediately assess whether it's something you can deal with. Unless you have a clear plan to recover from the problem, you should never just keep going on blindly in the hope it's all going to be fine somehow. 

There are a lot of judgement calls here that will depend on your application. If you're processing all the files in a directory and one turns out to be corrupt, there's no hard rule about the right thing to do. For some applications, it will make the most sense to roll everything back and leave things as they were. For others, it would make more sense to skip that file and process the rest. Or it might be best to pause and alert a human and give them a choice of what to do, or allow such configuration before the task starts.  You'll have to decide what makes the most sense given the context of how your application used and the ways in which it could cause problems if something goes wrong. This requires even more careful analysis when the software is serving a critical purpose: your judgement about how to handle missing sensor data will likely be different if you're designing a floor cleaning robot (where it may be more important to stop the robot immediately before it causes damage) vs flight control software (where you've put considerable design into redundancy, gradual degradation, and failure modes).