My first experience with COM involved a week of staring at a dialog box saying "Error -1" and twisting knobs in my code until the error dialog went away. This

My first experience with COM involved a week of staring at a dialog box saying "Error -1" and twisting knobs in my code until the error dialog went away. This was from a piece of COM that was entirely procedural, no UI at all. Yet someone had had the bright idea of (a) indicating an error with a dialog box instead of a return value, which brought the entire synchronous call to a screeching halt, and (b) reporting an absolutely useless error value. It would have been more useful had the COM code in question /crashed/ -- at least I could have debugged it. It's not just Microsoft, I've seen this "error -1" behavior in many APIs, on many systems. I've seen code that reported /any/ error as being "out of memory" (trying to blame it on someone else? I've never understood that one, if it's not just being lazy). Detailed error reporting is as much of an art as designing the working face of an API. The problem is, if you flub it, you're trying to mollify and calm an already irritated user. Think of errors as the first line in customer support, and get them right.