I screwed up a database query today, at the point where I was linking the data from two different tables. Most--if not all--tables involved in the query use a unique ID number to identify each row. My mistake was using those ID numbers to link two tables whose data, in the real world, wouldn't actually join up.
The scary thing was, though, when I spot-checked the total number of records returned, I was only off by three, out of over seventeen hundred. The upshot was that I wasted about a half-hour poking the data, looking for weird edge cases that could generate three extra records. In other words, it's like taking a powerful magnet to find the proverbial needle in the haystack, only to find that you're looking in the wrong haystack. D'oh!
Yes, in most situations, failures--particularly of the "quiet" genus and "incognito" species--are preferable to their EPIC cousins. This is not one of those situations. Code that utters a faint "eep!" as it fails to its fainting-couch will, more likely, be far more costly in the long run than code that has a screaming, rock star hissy fit and trashes the hotel room drywall with the opening band's guitars after it finds a brown M&M.
Moral of the story: Cherish your error-messages. Preferably in the QA stage or before.
