5 ms·

Yeah, it is bizarre how bad Microsoft error messages can be. I can just conceive designing a system that works this way, but I have absolutely no idea how some

by zmmmmm 17y ago

Yeah, it is bizarre how bad Microsoft error messages can be. I can just conceive designing a system that works this way, but I have absolutely no idea how someone would design such a system and have it produce absolutely no useful diagnostic message anywhere when it goes wrong.

InclinedPlane 17y ago
This is pretty much the worst case scenario in the fight between maintaining nice, human readable error messages for unsophisticated users and ugly, information dense technical error messages for aiding debugging for technical users (and developers). The result here is a message that helps neither users nor developers understand what went wrong or how to fix it. A message such as "fault in module Foo @ address 0x921851" or somesuch would be no more incomprehensible to the average user than this and a message such as "something went wrong, oh noes!" would be no more useless to developers. As it stands it's only through the magic of the internet and the fact that, thankfully, this message is at least a little unique that people are able to find out what this message really means and how to fix it.
kabdib 17y ago
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.

by zmmmmm 17y ago

InclinedPlane 17y ago

This is pretty much the worst case scenario in the fight between maintaining nice, human readable error messages for unsophisticated users and ugly, information dense technical error messages for aiding debugging for technical users (and developers). The result here is a message that helps neither users nor developers understand what went wrong or how to fix it. A message such as "fault in module Foo @ address 0x921851" or somesuch would be no more incomprehensible to the average user than this and a message such as "something went wrong, oh noes!" would be no more useless to developers. As it stands it's only through the magic of the internet and the fact that, thankfully, this message is at least a little unique that people are able to find out what this message really means and how to fix it.

kabdib 17y ago

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.