4 ms·

Preach. In the same vein, I hate when I get a random error code (e.g. "error 189") in an error message on the UI as a user. Am I supposed to remember that as a

Preach. In the same vein, I hate when I get a random error code (e.g. "error 189") in an error message on the UI as a user. Am I supposed to remember that as a user? Will support know what the error code means? Genuinely curious why some generic error messages (e.g. "Something happened") include these error codes.

MereInterest 4y ago
At least if there's an error code, I can search for that specific error code and see if anybody else has run into it. Seeing "Error 3bad617a" means that somebody else may have copy-pasted that same error message, and it might show up in search for "$PROGRAM_NAME 3bad617a". This is best if every location that can give an error has a unique code, but can be useful even if it is just parroting some low-level code. In other cases, an error code may be a standard value, and indicate that something is wrong with the inputs I provided as a user. If I see "Error saving file: 13", I may guess that the "13" was returned by some system call and is the error code EACCES or "Permission denied". I could test this by saving the file in another directory. The specific error code is useful for knowing what to do next, as error code 28 would be ENOSPC or "No space left on device", and I'd instead check if I ran out of disk space. (It would have been better if the error number had been passed through strerror() before display, but having the numeric code is still better than nothing.)
AlbertCory 4y ago
Because there's a programmer who knows what 189 means, and the fact that it happened out in the wild means he can potentially fix the problem. No, Support won't know, but they can pass the information on.
rippercushions 4y ago
Error codes are far better than lack of error codes. I was once involved in a large project to add unique, Googleable codes to all errors that could happen with $POPULAR_API, and support tickets dropped considerably after they were added.
wruza 4y ago
Numeric error codes are useful for troubleshooting, e.g. you can google “<program> error <code>”, or its developer can find where or around what exactly it’s localized. The “something happened” part usually comes from a generic error handler that reports surprising errors. E.g. your current graphics card driver messes with directx internals in a way that the game couldn’t foresee this sort of exception in that code path. So here you go, “unknown error 0x8000abcd”. Google it -> update your driver.
deleted 4y ago
[deleted]
fwlr 4y ago
Including arbitrary error codes in error messages is a good idea because it creates virtual gathering points for users searching for answers. From a comment I’ve made about errors in the past: “You should probably include the error code in the message (ERR0231), because that helps make the error message unique to this specific error situation and thus makes it functional as a “gathering point”. If you Google the error message and find others talking about the same error you experienced, that’s useful; if you Google the error message and find others talking about different errors on the same site, that is useless at best and could be harmful. (Concrete example: a multiplayer gaming platform reports a checksum of game files to a remote server to ensure all players are using the same version of the game. Scenario 1: The files are corrupt, the checksum is wrong, the error message is “Unable to validate game files”, the fix is to reinstall the game. Scenario 2: The user’s internet connection is temporarily degraded, the game is unable to get a response from the remote server, the error message is “Unable to validate game files”, the fix is to wait until connection improves. The unfortunate user from Scenario 2 is going to google their error message and get told to try the fix from Scenario 1. Now they’re re-downloading the game on their spotty connection.)“
jeroenhd 4y ago
For messages you don't expect mere mortals to solve, error codes may be useful as a filter. Some Windows Update errors can't be fixed without a reboot (or a debugger and the Windows source code) so 0xdead1337 is a fine code. You can Google it if you want to try anyway. Sometimes, errors happen because a whole chain of behaviour failed. The program is in a bad, irrecoverable state or contains a bug. The user can't fix it and the programmer that made the method may not even know the state can be impossible (i.e. code has been refactored). Sometimes, error codes are more about helping the developers pinpoint a bug than they're about helping the user. That said, things like "database corrupt" or "no connection to API server" should just be displayed rather than muffled away. In my opinion, these impossible error codes should be accompanied with a support phone number or email address.
secretsatan 4y ago
Sometimes they're unavoidable, when you simply have no idea, or can't think of all the things that could go wrong, it's better to give an error code than a generic, something went wrong, message. I've had worse though, when a UX design specified a specific error message and a developer blindly followed it and simply remapped errors to the given message, ignoring what the actual error was, misleading the users and the developers. I've told UX to never include error messages again..

MereInterest 4y ago

At least if there's an error code, I can search for that specific error code and see if anybody else has run into it. Seeing "Error 3bad617a" means that somebody else may have copy-pasted that same error message, and it might show up in search for "$PROGRAM_NAME 3bad617a". This is best if every location that can give an error has a unique code, but can be useful even if it is just parroting some low-level code. In other cases, an error code may be a standard value, and indicate that something is wrong with the inputs I provided as a user. If I see "Error saving file: 13", I may guess that the "13" was returned by some system call and is the error code EACCES or "Permission denied". I could test this by saving the file in another directory. The specific error code is useful for knowing what to do next, as error code 28 would be ENOSPC or "No space left on device", and I'd instead check if I ran out of disk space. (It would have been better if the error number had been passed through strerror() before display, but having the numeric code is still better than nothing.)

AlbertCory 4y ago

Because there's a programmer who knows what 189 means, and the fact that it happened out in the wild means he can potentially fix the problem. No, Support won't know, but they can pass the information on.

rippercushions 4y ago

Error codes are far better than lack of error codes. I was once involved in a large project to add unique, Googleable codes to all errors that could happen with $POPULAR_API, and support tickets dropped considerably after they were added.

wruza 4y ago

Numeric error codes are useful for troubleshooting, e.g. you can google “<program> error <code>”, or its developer can find where or around what exactly it’s localized. The “something happened” part usually comes from a generic error handler that reports surprising errors. E.g. your current graphics card driver messes with directx internals in a way that the game couldn’t foresee this sort of exception in that code path. So here you go, “unknown error 0x8000abcd”. Google it -> update your driver.

deleted 4y ago

[deleted]

fwlr 4y ago

Including arbitrary error codes in error messages is a good idea because it creates virtual gathering points for users searching for answers. From a comment I’ve made about errors in the past: “You should probably include the error code in the message (ERR0231), because that helps make the error message unique to this specific error situation and thus makes it functional as a “gathering point”. If you Google the error message and find others talking about the same error you experienced, that’s useful; if you Google the error message and find others talking about different errors on the same site, that is useless at best and could be harmful. (Concrete example: a multiplayer gaming platform reports a checksum of game files to a remote server to ensure all players are using the same version of the game. Scenario 1: The files are corrupt, the checksum is wrong, the error message is “Unable to validate game files”, the fix is to reinstall the game. Scenario 2: The user’s internet connection is temporarily degraded, the game is unable to get a response from the remote server, the error message is “Unable to validate game files”, the fix is to wait until connection improves. The unfortunate user from Scenario 2 is going to google their error message and get told to try the fix from Scenario 1. Now they’re re-downloading the game on their spotty connection.)“

jeroenhd 4y ago

For messages you don't expect mere mortals to solve, error codes may be useful as a filter. Some Windows Update errors can't be fixed without a reboot (or a debugger and the Windows source code) so 0xdead1337 is a fine code. You can Google it if you want to try anyway. Sometimes, errors happen because a whole chain of behaviour failed. The program is in a bad, irrecoverable state or contains a bug. The user can't fix it and the programmer that made the method may not even know the state can be impossible (i.e. code has been refactored). Sometimes, error codes are more about helping the developers pinpoint a bug than they're about helping the user. That said, things like "database corrupt" or "no connection to API server" should just be displayed rather than muffled away. In my opinion, these impossible error codes should be accompanied with a support phone number or email address.

secretsatan 4y ago

Sometimes they're unavoidable, when you simply have no idea, or can't think of all the things that could go wrong, it's better to give an error code than a generic, something went wrong, message. I've had worse though, when a UX design specified a specific error message and a developer blindly followed it and simply remapped errors to the given message, ignoring what the actual error was, misleading the users and the developers. I've told UX to never include error messages again..