I really ought to dig up a reference for this, but there are strong echoes from the past here. Margaret Hamilton (who coined the term 'software engineering' and can be seen standing next to a tall pile of green bar printouts of the Apollo software) brought her daughter to work one weekend during the Apollo program and she (daughter) fiddled with the buttons and caused an error condition. Hamilton, based on this, argued that the software should account for the possibility of mistakes. Management's view was that the highly-trained astronauts wouldn't make mistakes. In time, Hamilton prevailed, and was proven correct.
Having seen what happens when you let a toddler start randomly pressing stuff on an Android tablet she was spot on, and if anything every environment should be out through this.
The recent japanese lander had something like this happen a while back. The altitude radar noticed a sudden 2km drop in ground-level, and the system assumed it was broken and stopped using that data.
Turns out it just flew over a cliff edge that actually does that. Completely by accident.
They picked a new landing site late in the program and didn't get the topography near that site, or run enough combinations through the software in test.
In general software development it's usually not a problem if your program crashes, then you can fix the bug and run it again. If the thing that crashes is a lunar lander however, you should put a bit more effort into covering all the eventualities...
That might still be OK if that path literally should never happen in normal operation, but us used, e.g., to handle an error, or at least log it, if the impossible happens because the software is deployed in some unexpected configuration
While we think "this cannot ever happen" in a lot of cases it can, in ways you did not consider. Both for good and bad