We check literally everything we get from a user or outside entity (network, file, shared memory, etc).
My pet peeve with young coders. Condition testing is hardly ever a consideration. You clearly learned back when coding was structured and had rules.
Good question. However, the adding such checks on every outside chance of a user doing every possible "Stupid User Trick" would increase the size of the core code to unweildlyness.
I too, cut my teeth on FORTRAN and Hollerith punch cards. I designed and programmed a database for the Emergency Food Bank I founded more than 30 years ago. I designed it so that we could take a person off the line of applicants and sit them down at the keyboard and with two hours training have them do intake interviews. However, it took over a year of my work to "idiot proof" that input process to prevent these people from finding ways to break the database or input garbage. After that year, though, that database ran for twenty years with no issues.
A supervisor could check the input at the end of the day and correct any errors if there were any, usually not. At the end of the month I could check the error log, and usually the number of corrected errors could be counted on the fingers of one hand.
However, for that first year, I was frequently astounded at the ways the users came up with to crash the system and the database or to input errors. . . and of course, by their very nature, they were always ways I had not anticipated. No programmer or designer can anticipate everything, or as a battle planner should realize, "no battle plan survives the first contact with the enemy!"