Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What "standard" application return/exit codes should an application support?

Is there such thing as a standard set of application return codes? Things like returning 0 for success 1 for failure, and then so on?

I have a Windows Server application that I am adding some return error codes and wanted to stick to standard codes in addition to the app specific ones that I will need.

like image 604
MikeD Avatar asked Oct 08 '09 16:10

MikeD


People also ask

What is a successful exit code?

Success is traditionally represented with exit 0 ; failure is normally indicated with a non-zero exit-code. This value can indicate different reasons for failure.

What is the normal value of an exit status?

This is a value between 0 and 255 that the exiting process passes as an argument to exit . Normally you should use the exit status to report very broad information about success or failure.

When a user program exits what is done with the program's return value?

The return value from main is passed to the exit function, which for values zero, EXIT_SUCCESS or EXIT_FAILURE may translate it to “an implementation defined form” of successful termination or unsuccessful termination.

Why is it important to use exit codes?

The list constructs use exit codes to understand whether a command has successfully executed or not. If scripts do not properly use exit codes, any user of those scripts who use more advanced commands such as list constructs will get unexpected results on failures.


2 Answers

I think the only standard is 0 for success and non-zero for failure. And that's more of a convention than a standard.

like image 115
Douglas Leeder Avatar answered Nov 15 '22 19:11

Douglas Leeder


Maybe you can adopt some of the Unix conventions.

In another answer, the user David suggested

sysexits.h has a list of standard exit codes. It seems to date back to at least 1993 and some big projects like Postfix use it, so I imagine it's the way to go.

From the OpenBSD man page:

According to style(9), it is not good practice to call exit(3) with arbi- trary values to indicate a failure condition when ending a program. In- stead, the pre-defined exit codes from sysexits should be used, so the caller of the process can get a rough estimation about the failure class without looking up the source code.

This is the list as it appears on a Debian system:

#define EX_USAGE        64      /* command line usage error */
#define EX_DATAERR      65      /* data format error */
#define EX_NOINPUT      66      /* cannot open input */    
#define EX_NOUSER       67      /* addressee unknown */    
#define EX_NOHOST       68      /* host name unknown */
#define EX_UNAVAILABLE  69      /* service unavailable */
#define EX_SOFTWARE     70      /* internal software error */
#define EX_OSERR        71      /* system error (e.g., can't fork) */
#define EX_OSFILE       72      /* critical OS file missing */
#define EX_CANTCREAT    73      /* can't create (user) output file */
#define EX_IOERR        74      /* input/output error */
#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */
#define EX_PROTOCOL     76      /* remote error in protocol */
#define EX_NOPERM       77      /* permission denied */
#define EX_CONFIG       78      /* configuration error */

Inside the file /usr/include/sysexits.h one can find more detailed descriptions of these error codes.

like image 35
gioele Avatar answered Nov 15 '22 18:11

gioele