Some errors, such as a value out-of-range values, might be the result of erroneous user input. If the program is interactive, it can prompt Interactive programs typically handle such errors by rejecting the input and prompting the user for an acceptable value. With other errors, such as a resource allocation failure, the system may have little choice other but to shut downServers reject invalid user input by indicating an error to the client while at the same continuing to respond to other clients. All robust programs must be prepared to gracefully handle resource exhaustion such as low memory or disk space conditions, at a minimum by preventing the loss of user data kept in volatile storage. Interactive programs may give the user the option to save data on an alternate medium, while network servers may respond by reducing throughput or otherwise degrading the quality of service. However, when certain kinds of errors are detected, such as irrecoverable logic errors, rather than risk data corruption by continuing to execute in an indeterminate state, the appropriate strategy may be for the system to quickly shut down, allowing the operator to start it afresh in a determinate state.
Wiki Markup |
---|
\[[ISO/IEC PDTR 24772|AA. References#ISO/IEC PDTR 24772]\] Section 6.47, "REU Termination strategy," says: |
...
C99 provides several options for program termination, including exit()
, returning from main()
, _Exit()
, and abort()
.
exit()
The C standard Calling exit()
causes normal program termination to occur. Other than returning from main()
, calling exit()
function is typically used the typical way to end a program. It The function takes one argument of type int
, which should be either EXIT_SUCCESS
or EXIT_FAILURE
indicating normal successful or abnormal unsuccessful termination. Zero is equally portable and well understood, respectively. The value of EXIT_SUCCESS
is guaranteed to be zero. C99 Section 7.20.4.3 says "If the value of status is zero or EXIT_SUCCESS
, an implementation-defined form of the status successful termination is returned." The exit()
function never returns.
...
Functions registered by the atexit()
function are called by exit()
or upon normal completion of main()
.
Note that the behavior of a program that calls exit()
from an atexit
handler is undefined (see undefined behavior 172 in Annex J of C99). See also ENV32-C. All atexit handlers must return normally.
return
from main()
Because Returning from main()
is defined to have return type int
, another valid exit strategy is to simply use a return
statement causes normal program termination to occur. This is the preferred way to terminate a program. Evaluating the return
statement has the same effect as calling exit()
with the same argument.
Code Block | ||
---|---|---|
| ||
int main(int argc, char **argv) { /* ... */ if (/* something really bad happened */) { return EXIT_FAILURE; } /* ... */ return EXIT_SUCCESS; } |
...
However, exiting from main is conditional on correctly handling all errors in a way that does not force premature termination (see ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy and ERR05-C. Application-independent code should provide error detection without dictating error handling).
_Exit()
A more abrupt function, Calling _Exit()
causes normal program termination to occur. Like the exit()
function _Exit()
also takes one argument of type int
and never returns. The standard specifies that _Exit()
also closes open file descriptors but does not specify However, unlike exit()
, whether _Exit()
closes open streams, flushes file stream buffers #1, or deletes temporary files is implementation-defined. Functions registered by atexit()
are not executed.
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="a92be123-a122-422d-861d-201cca3e9e74"><ac:parameter ac:name="">1</ac:parameter></ac:structured-macro>\[1\] Note that POSIX ^®^ strengthens the specification for {{_Exit()}} by prohibiting the function from flushing stream buffers. See the {{documentation|http://www.opengroup.org/onlinepubs/9699919799/functions/_Exit.html]}} of the function in [\[Open Group 08\]|AA. References#Open Group 08]. |
Code Block | ||
---|---|---|
| ||
#include <stdlib.h> /* ... */ if (/* something really bad happened */) { _Exit(EXIT_FAILURE); } |
The _exit()
function is an alias for _Exit()
.
abort()
The quickest and most abrupt way to terminate a program, Calling abort()
takes no arguments and always signifies abnormal causes abnormal program termination to the operating systemoccur unless the SIGABRT
signal is caught and the signal handler calls exit()
or _Exit()
.
Code Block | ||
---|---|---|
| ||
#include <stdlib.h> /* ... */ if (/* something really bad happened */) { abort(); } |
The abortAs with _Exit()
function causes abnormal program termination to occur, unless the signal SIGABRT
is caught and the signal handler does not return.Whether , whether open streams with unwritten buffered data are flushed, open streams are closed #2, or temporary files are removed is implementation-defined. Functions registered by atexit()
are not executed (see ERR06-C. Understand the termination behavior of assert() and abort()).
Wiki Markup |
---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f95bde4f-839b-49a0-81d2-faf2b901a0af"><ac:parameter ac:name="">2</ac:parameter></ac:structured-macro>\[2\] Unlike in the case of {{\_Exit()}}, POSIX ^®^ explicitly permits but does not require implementations to flush stream buffers. See the {{documentation|http://www.opengroup.org/onlinepubs/9699919799/functions/abort.html]}} of the function in [\[Open Group 08\]|AA. References#Open Group 08]. |
Summary
The following table summarizes the exit behavior of the program termination functions.
Function | Closes file descriptors | Flushes buffers | Removes | Calls | Program | ||||
---|---|---|---|---|---|---|---|---|---|
|
| unspecified unspecified |
| unspecified | no abnormal | ||||
|
| yes | unspecified unspecified |
| no normal | ||||
|
| yes yes |
| yes yes | |||||
return from | yes | yes | yes | yes
|
|
|
|
Table legend:
- – Yes. The specified action is performed.
- – No. The specified action is not performed.
- – Implementation-defined. Whether the specified action is performed depends on the implementation.
Noncompliant Code Example
...