Yes, there are multiple problems here that interplay in a really bad way and that's one of them. But the input processing/validation step is the first point of contact with that particular flight plan and it should have never progressed beyond that state.
It all hinges on a whole bunch of assumptions and each and every one of those should be dealt with structurally rather than by patching things over.
Just from reading TFA I see a very long list of things that would need attention. Quick recap:
- validate all input
- ensure the system can never stall on any one record
- the system will occasionally come across malformed input which needs a process
- it won't be immediately clear whether the system or the input is at fault, which needs a process
- testing will need to take these scenarios into account
- negative tests will need to be created (such as: purposefully malformed input)
- attempts should be made to force the system into undefined states using malformed and well formed input
- a supervisor mechanism needs to be built into the system that checks overall system health
And probably many more besides. But this is what I gather from the article is what they'll need at a minimum. Typically once you start digging into what it would take to implement any of these you'll run into new things that also need fixing.
As for the last bit of your comment: I'm quite sure that those standards were in play for this particular piece of software, the question is whether or not they were properly applied and even then there are no guarantees against mistakes, they can and do happen. All that those standards manage to do is to reduce their frequency by catching the bulk of them. But some do slip through, and always will. Perfect software never is.