How do you use exit status code? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

When the program run successfully, usually the program will return 0 status. If there any problems, the we can return value other than 0 at exit. With Exceptions, (as long as the problem is not undefined behaviour), we can return 0 value even though program is unsuccessfully finished.

My questions is:

• Is the status code used to identify what problem that occured? Maybe for tracking bugs or documentation purpose?
• Is exception have to return status code other than 0 or is it bad to return non 0 exit code?
• How do you decide which status code to be returned? Can I return the same status code for different errors?

Generally, the question is:

• How do you use exit status code?

Answer 1

How exit status codes are used depends for a very large part on what kind of application it is. The main use of exit status codes is when you want to automate the execution of applications using scripting.

If the application is an interactive application, where the expectation is that the user always directly interacts with the application, then exit status codes are largely ignored. There is never an (automated) decision to make what to do next depending on how the application exited.

If the application is designed to be interactive, but also has a 'batch' mode for occasional running in a script, then the application will usually indicate either success or failure, like a boolean status code.

If the designers of the application really had scripting on their mind, then they probably have added multiple exit status codes for different kinds of failure, so that script authors can react accordingly. These are user-level errors and will typically map to one or more internal error situations.

Answer 2

Exceptions and exit status codes are two very different things. Exceptions are at the scope of the application; exit status codes are at the scope of the operating system.

When an application calls another one, basically, the only standard way for it to determine that the callee finished successfully is the exit status code. 0 means success. Anything else means failure. The fact that there is no standard for which code is which means that determining the source of the failure often requires to do an additional step of browsing the documentation, when available. Given the vast diversity of issues, creating such standard would be both practically and theoretically impossible: even if you can standardize some errors, such as "file not found", an exit code, that is a simple number, won't be detailed enough: in a case of a file not being found, which file exactly was expected?

This flaw is exactly the same as the one which pushed to abandon error codes within a program and use exceptions instead.

Exceptions:

• Are often explicit, as they contain the type, the summary and additional data. The type FileNotFoundException coupled with the path of the expected file and the stack trace helps identifying very precisely the problem, both as a user of a program and as a programmer—if it's the fault of the program for being unable to find the file or not being able to fallback to another option.

• Can be caught within the application itself.

When it comes to inter-process communication, web services, for example, make it possible to emulate at least the first benefit of the exceptions, by providing JSON/XML representation of an error, rather than just a error code.

Answer 3

In a shell program you can use them to make some decisions. In bash $? is the variable which holds the status of the last program that exited.

if [$? -eq 0 ]; then
   echo "Everything is okay"
else
   echo "Something is terribly wrong!"
fi

Answer 4

Exit codes are operating system specific. In C99, <stdlib.h> knows about exit(3) and EXIT_SUCCESS & EXIT_FAILURE. I'm focusing on Linux.

POSIX and Linux systems accept 256 different values to exit, with 0 being EXIT_SUCCESS and other non-zero values (1 to 255) for some kind of failures.

BSD has attempted to standardize exit codes; see the file <sysexits.h>

^{You might have several exit codes (e.g. a dozen different of them). Don't forget to document them.}

The waitpid(2) syscall can retrieve the exit code of a forked child process, and the status is also returned by system(3)

Exceptions ought to be caught and handled, at least by the runtime system (e.g. on C++ or Java or Ocaml).

Some programs are registering functions with atexit(3) and some daemons or servers are handling SIGTERM signal (see signal(7)), this is why on Linux it is not advisable to kill(2) processes with SIGKILL (you should try SIGTERM then SIGQUIT before the unhandable SIGKILL, to let a well behaved program clean its mess before termination, e.g. let some database manager flush its state to disk).

Answer 5

You use exit codes when the application will be ran by a seperate process, which can make decisions based upon the results.

What exit code you should return under any specific circumstances, will be between you and your caller. I typically use exit codes for scheduled jobs/task and limit the return to sucess and failure. Really it's all up to you.