One of the problems I face in this mission is that at various points the software engineers who've worked on various other stinking piles of encrusted cruft that I have to work with to do my job have either taken the approach that one doesn't need to worry about whether or not the input they get is valid, or the approach that one should attempt to be
helpfuland carry on regardless and hope it works out for the best.
My commonly quoted example for this is the difference between free(), delete and delete . It's the wrong sort of distinction, it could easily be implemented such that you knew if the wrong one was called, and never is. Code that makes the mistake usually works, but occasionally fails mysteriously.
The example that's actually occasioned this rant is the lj HTML Validator. This will happily fail to notice that you've closed the wrong sort of tag, or not opened your <table>, but whinges bitterly about missing "s… sometimes. Most of the time the bogus HTML will just get posted anyway and then muck up someone's fiends page.
Web browsers themselves do this too – they'll typically try and display a page even if it has errors, and won't indicate this to you in any way.
The problem with this soft failure model is that it inures users, and they carry on making the same sorts of mistakes, and the more prevalent the mistakes are the harder it is to go through and fix them all. And every one time in 100 (or 1 in 10, or 1 in 10,000) something fails and the user says "oh, my computer's done something strange again".
ETA: Or, indeed, not complain when you write <table> as <table> in your entry and hence muck up the rest of it... *sigh*