Jeff, I totally agree that such error code-based messages are not great to say the least (who wouldn't BTW!).

OTOH, I think that "Don't _ever_ use error codes" is too easy a conclusion.

Because you assume:
a) we (the devs) can always know the cause of the error.
And/or:
b) there is always a _meaningful_ message associated with the error code.

Boy! If a) were true, our apps could in most cases avoid or workaround the error.
As for b), while an error message is usually way better than a code, it's not always available. And it's often not self-speaking (e.g. "An argument is invalid"). In the case of b), I often find myself appending the error code to the message because if users have to get back to you, there is _not one single chance_ they'll report the error message correctly (unless they send you a screenshot).

The problem is with errors we were not able to anticipate. In most such cases, expecting to be able to give useful diagnostic to the user is over-optimistic at best.

Cheers,

I agree with the last comment. I always logs the errors in a human readable form, but most times the errors come from 3rd party software (including windows).

You cannot give a meaning to that errors (most time unexpected errors catched). The COM errors as show in your blog are a real headache as a user and also as a developer.

To solve the error code problem we must start fixing it from the verylow (OS) and going up thru the software chain.

Hope that my bad english is not a problem.

Nice blog.

I certainly try to follow Alan Cooper's guidelines whenever I need to present information to the user about an error but unfortunately as long as my software relies upon other systems that still use error codes there will always be cases that can be very difficult to deal with.

Just as annoying as error codes are error boxes that don't know what went wrong and give you three or more possible reasons why the error occurred: "Either your Internet connection is down, the server is offline, or the server cannot accept any more connections". Some more code in the error handling could probably pinpoint the problem before informing the user.

I always do both. Give a helpful error-message and the error-code producing the problem.

The first is for helping the users to find the solution for the problem themselfs, the errorcode to help the support-people to track down the problem better.

Not all helpful error-messages fit into a popup-window and an error-code often help to find solutions using Google.

BTW: Your first screenshot more looks like a missing entry inside the language-ressource-file than a planned error-message.

BTW2: Errorcodes are still very common, especially when different systems have to work together without user-interaction.

Regards, Lothar

http://www.electrosonics.net/technotes/xperror0x8024402C.htm

googled in 5 seconds. im totally happy with errorcodes :-) especially if the program that produces this problem is multilanguage capable - or have you ever seen multilanguage errorcodes ? *gg*

Error codes and those totally useless messages that just frustrate - like 'Error connecting to database', 'failed to read file', 'error reading'

Put the name of the file, say what you were trying to do, put the OS error message. Give the poor user some sort of a fair chance at using your program.

Worse, libraries that display their own messages without the programmer being able to trap them. I came across a wonderful one recently - 'See the 5185 error code documentation for details. axServerConnect AdsConnect' - now thats a useful error message.

Ian

I agree that messageboxes that contain just error codes are utterly useless.

However, messageboxes that contain textual descriptions of the error can be equally as useless. Consider the case of a file open error. The lazy programmer thinks the file open will never fail and doesn't check that case. The not-so-lazy program catches it and displays a messagebox with the ever helpful "File open error" message. Sigh. What file didn't open?

How about something really usefull like:
+----------------------------------+
| File open error
| C:\data\myfile.dat
| at line 428 of myopenfile.cpp
| OK
+----------------------------------+

This serves two puposes. 1) it lets the user know that myfile.dat is missing. and 2)if they need to contact tech support, the messagebox contains useful information to give back to the developer.

If you're hot about error codes, than the description could be "File open error (Error code 0x12345)"

- Coleman

So, who is General Failure and why is he reading my hard disk?

> unfortunately as long as my software relies upon other systems that still use error codes there will always be cases that can be very difficult to deal with

Here's what I would do in this situation

1. Have the software "phone home" (with user's consent) when it encounters an error.

2. Log all errors.

3. For the top 5 errors, implement help that follows Cooper's guidelines

4. Ignore the rest, since the top 5 probably account for 80-90 percent of errors users encounter.

The critical piece here is getting a list of the ACTUAL errors users are encountering, rather than playing a guessing game.

> OTOH, I think that "Don't _ever_ use error codes" is too easy a conclusion

Maybe I should clarify this: don't ever present error codes alone to the user. You can parse them internally if you need to, but presenting them as-is to a user is just irresponsible.

Having a Cooper-compliant error dialog *and* an error code doesn't hurt, of course. Users will just ignore the code.

Oh god yes, I hate error codes with a passion. As I deal with mainframes all day at work (go go os/400) I see a TON of them... and end up just googling the number to find out what it means.

Every developer should be REQUIRED to read About Face 2.0 if they have anything to do with UI and especially if they have to create the output that comes with error messages.

I agree with the principle, but error codes often hold valuable information for actually fixing the problem. An error message which just presents a cryptic error message is bad, but not as worthless as a pretty but totally generic error message. I can google "0x8024402c", but a smiley faced "Sorry, I just deleted your files, have a nice day" message is worthless. (c.f. Sad Mac image). Also, error codes are a lot more efficient for communicating with tech support or in online help forums than long error messages.

Error codes are a functional counterpoint to knowledgebase ID's, since they allow us to solve problems in an organized and repeatable manner. A good error code is really an error ID, which is valuable.

I propose that error messages be made available via an "advanced" button or tab, or in parenthetical information at the end of a nicely written, human-centric error message:

---------------
"Windows Defender was unable to complete updates. Until this is resolved, Windows Defender will not be able to protect your computer against newly emerging virus threats.

To resolve this condition, please contact technical support and reference error condition 105-401-2238.
---------------

Oh, and I totally agree that no one should ever be shown hex-formatted data in this day and age. That's pathetic.

Error codes aren't for users, they are for developers and support staff.

If you let a user think he has a clue what they're doing, then they try to fix things, and NOTHING good ever happens then.

Frankly, I think that the real problem are the USERS, not the codes. If you could just keep people away from computers, they would be so much more stable(both the computer and the users.)

I say ban computer users today. What say we start an online petition?

Doesn't that look like a COM error? Notoriously unhelpful, those.

I agree with the commenter who noted that an error code (as distinct from just a message) is more international. Assuming you don't have the wherewithal to get all the errors translatable. As a corollary, this jibes with the folks who note that an error code is for other software to read -- it is a bad practice, I believe, to have to parse an error message string to determine in software what error occured. Since, for example, the string might have been translated.

But that doesn't mean that _users_ have to see them, unless the problem is a) catastrophic and b) the point is to be able to read that error code to a help technician. That would not be the most common case, no.

>Put the name of the file, say what you were
>trying to do, put the OS error message.

There can be security reasons not to be broadcasting the names of things to random users. Certainly in a Web app.

Sigh. I wish as many people comment on my site as on yours. :)

> I agree with the commenter who noted that an error code (as distinct from just a message) is more international.

If everything is a number, then it's a snap to internationalize everything. You might as well build your whole UI with numbers to save some cash. Of course nobody will be able to *use* your app, but hey, we saved some bucks.

I don't subscribe to this "we must do things to make our apps easier to translate" theory, which also came up in the icon/text post. It's just not true-- you're only shuffling the costs around, not saving anything.

> I can google "0x8024402c"

Isn't the whole point of computers to take on this kind of mind-numbing work? Like, say, manually looking up error codes?

But I definitely agree that having an additional error code in the (polite, illuminating, helpful) error message somewhere is fine. Preferably behind a " More >> " button.

Maybe we as developers are affraid that the user will see that we did something wrong or show that we did some crappy implementation.

Maybe error 0x32324234 0x123123123123 0x213123 sounds more advanced then:

"Your machine ran out of memory, we thought that 640k should be enough for anyone. Please reboot your machine and try to recreate whatever data you lost. In the future, please try saving your data as often as you can."

Anyway I was wondering, what about error reporting software. Do they ever work ?

Scott: With all fairness I thought about it, but my lateness to the party wanted me to comment somewhere closer to the time when I could get to it.

Jeff:
"Here's what I would do in this situation"

Funny thing is, Windows Error Reporting does practically all 4 of those. There's an option to contact support. Common error messages retrieve a description if there's a resolution all within the same dialog. I've still received lame "Your video card stinks" or similar messages, but at least it was something. If you use Event Viewer and use the help link, it finds the error code and gets a list of knowledge base articles and other resources. 98% of all errors in the event log I've fixed following something from this list, never having to stray even one level away. There are some messages with no response in a "Sorry, figure it out yourself" (which feels more like a middle finger to me) but luckily there's searching for the descriptive error message which covers the bulk of what is missed.

I'm honestly surprised this wasn't a product that followed the existing error reporting. It's an ONLINE anti-virus application. It may function but is no real "Defender" if it's definitions are out of date. Using the existing error reporting service or at least something with similar functionality seems minimum. You want users figuring this out quickly if they can, reducing your support load. You most certainly would get more support calls if you couldn't find the right information to fix the problem quickly.

I agree that both a helpful message and an error code should be presented to the user.
However, a more pressing issue I think is the ability to copy and paste errors. Too many times am I presented with a message box that I can't select the text for and copy, and find myself manualy copying the error message (or the shorted possible uniquely identifiable substring of it) into google manualy.
The ideal solution (other than no errors) is a short, well designed error dialog that presents key information that the user may be able to use to fix the problem, a textbox with a more detailed description and an errorcode, that can be selected and copied, and an option to look it up on a database of common problems for your website so you can post fixes and hotpatches as you find them.

> is a short, well designed error dialog that presents key information that the user may be able to use to fix the problem, a textbox with a more detailed description and an errorcode, that can be selected and copied,

I agree. Take a look at the screenshots in these articles:

http://www.codeproject.com/dotnet/ExceptionHandling.asp

http://www.codeproject.com/aspnet/ASPNETExceptionHandling.asp

>You might as well build your whole UI with numbers to save some cash.

Uh, what I SAID was that users should not have to see those numbers, but they are suitable as machine-readable data.

>I don't subscribe to this "we must do things to make our apps easier to translate" theory.

Well, we do. Windows is translated into, what, 36 languages and counting? You can bet that those folks organize and manage their errors by number, not by text. They localize the text for those errors, but no piece of code anywhere in Windows should ever rely on an error message *string*.

I didn't say it was cheaper to translate. What the benefit is is that it simply makes it *practical* to translate thousands of error messages into dozens of language if you can keep track of what the errors are. And the practical way to do that is to give them a unique, globally neutral identifier -- i.e, a number.

"I agree. Take a look at the screenshots in these articles"
It's a very good progress over usual errors. One, and the only I can really think of, is that the copy and pastable part of the message is too long in itself. You really need a short bit that novice users can copy and paste into google that is most likely to come up with a result, and is obviously so. But I like it, I may have to start writing my own custom error dialogs based on this.

>However, a more pressing issue I think is the >ability to copy and paste errors. Too many times am >I presented with a message box that I can't select >the text for and copy, and find myself manualy >copying the error message (or the shorted possible >uniquely identifiable substring of it) into google >manualy.

Actually, pressing CTRL+C when you see the message box should copy its contents into the clipboard in most cases..

Here's a list of the DNAS error codes from Playstation 2's online connectivity

http://www.broadbandreports.com/faq/dnas?text=1

examples:

-101 sceDNAS2_SS_SERVER_BUSY
DNAS server is busy. "DNAS Error (-101) The network authentication server is busy. Please try again later."

-102 sceDNAS2_SS_BEFORE_SERVICE
DNAS authentication service period has not started for this title. "DNAS Error (-102) This software title is not in service."

-103 sceDNAS2_SS_OUT_OF_SERVICE
DNAS authentication service period has ended for this title. "DNAS Error (-103) This software title is not in service."

I think error codes are a very valid and useful way to describe errors. Often, the user IS not very tech-savvy and a useful error message like "your raid partition has just lost its connection to the PCI bus" means just as little to them as saying Error: 2615. However, when they call tech support if they have an error code, they will say, "Hey, i have error 2615, what should i do" whereas the longer message will most likely come out as, "HELP, my PCI raid missed the bus" or something equally as nonsensical.
Also, the presence of an error message implies that there is a text somewhere with a full text of what that message implies. Usually in the back of the manual. If you can't go look up an error message, you have no reason to be trying the problem yourself anyway.

Having just hit the ole TFS 26105, I'm in no mood to sing the praises of error codes. Let me add one thing: if the user cannot do anything about the exception, don't bother them with the information. If the program can continue, log it and go. If it can't explain to the user that the program has encountered a problem, it has already reported the problem to whatever entity must know about it, and that the help desk will contact the user if additional info is needed. These days, in the time it takes the users to do anything, the error can be logged, an email alert sent to a tier 1 helpdesk, and the issue resolved, with the support team contacting the user back and telling them they're ok to proceed.