This isn't a case of "Robustness principle". Not crashing on invalid input is just plain old decent programming, not to mention secure programming. Programs should not crash on invalid inputs, period. "Robustness" as in the robustness principle refers to trying to actually process invalid data and go make a guess at what the functionality should be.
In fact, you can make quite a case that "robustness" as defined that way is responsible for the horrible mess that HTML and cross-browser compatibility is these days. For instance, if you improperly close tags, or overlap tags, IE (and others I assume) will dutifully go about trying to figure out what you meant: being very "robust" in their interpretation of input outside the spec.
By implementing behaviour outside the spec (being "robust"), you are implicitly extending the spec, and every other browser has to implement unspecified behaviour in the same way.
Reminds me of one of my first jobs. I needed to convert some data into a odd file format based on 100 or so pages of documentation and upload it to an FTP. Problem was the first version I wrote caused their system to crash...
At uni in a software testing subject I was given an assignment to read various input files (some valid, some invalid). If your program crashes, you would get 0 marks. It made for a stressful assignment execution day, but it was a good lesson.
In fact, you can make quite a case that "robustness" as defined that way is responsible for the horrible mess that HTML and cross-browser compatibility is these days. For instance, if you improperly close tags, or overlap tags, IE (and others I assume) will dutifully go about trying to figure out what you meant: being very "robust" in their interpretation of input outside the spec.
By implementing behaviour outside the spec (being "robust"), you are implicitly extending the spec, and every other browser has to implement unspecified behaviour in the same way.