I explained to the developer what I was looking for and I realized that I shouldn’t just ask for a non-zero code. (Zero is the default code for saying that ‘the [program|function|script] completed successfully’.) So I decided to do a little homework.
Here are some standard exit codes that are useful for troubleshooting, or in my case, alerting the developer of which exit code would be appropriate.
The error that we needed wasn’t specifically provided, but codes 50 or 1003 were pretty good. When all else fails you can send a code 1. The important thing is to know what to do when the error code is received.
One of the most frustrating errors is 1603. It’s kind of a generic fail-safe error that pretty much tells you that you’re hosed, but doesn’t give much to go on. (It’s actual definition is “Fatal error during installation.”) As a general rule I suggest to developers that they shy away from this error if there is any other error more appropriate. Using 1603 just incites rage. Google it and you’ll see a ton of hits, many of which are still unanswered. They range from everything imaginable.
When you call for support from an application vendor one of the first things they’ll ask you (right before they blame it on the hardware manufacturer, platform manufacturer, or the HVAC guy) is what your exit code is. So it’s a good idea to know it. You’ll usually find it in a log file (generated by the installation), or an event log. Sometimes a dialog will pop-up during the installation with the exit code.
As I started to investigate exit codes, I found myself thinking about setting up PDQ to work with remote workers. A good post. I recommend it.
Oh yeah, since everyone seems to have their own flavor that they prefer, return codes and error codes are synonymous with exit codes.
So go forth and know thy [exit|error|return] code.
Facing other troubleshooting challenges? Maybe one of these posts can help:
