Page History

Some errors, such as out-of-range values, might be the result of erroneous user input. Interactive programs typically handle such errors by rejecting the input and prompting the user for an acceptable value. Servers reject invalid user input by indicating an error to the client while at the same time continuing to service other clients' valid requests. 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 TR 24772|AA. Bibliography#ISO/IEC TR 24772]\], Section 6.47, "REU Termination strategy," says

When a fault is detected, there are many ways in which a system can react. The quickest and most noticeable way is to fail hard, also known as fail fast or fail stop. The reaction to a detected fault is to immediately halt the system. Alternatively, the reaction to a detected fault could be to fail soft. The system would keep working with the faults present, but the performance of the system would be degraded. Systems used in a high availability environment such as telephone switching centers, e-commerce, etc. would likely use a fail soft approach. What is actually done in a fail soft approach can vary depending on whether the system is used for safety critical or security critical purposes. For fail safe systems, such as flight controllers, traffic signals, or medical monitoring systems, there would be no effort to meet normal operational requirements, but rather to limit the damage or danger caused by the fault. A system that fails securely, such as cryptologic systems, would maintain maximum security when a fault is detected, possibly through a denial of service.

...

int main(int argc, char **argv) {
  /* ... */
  if (/* something really bad happened */) {
    return EXIT_FAILURE;
  }
  /* ... */
  return EXIT_SUCCESS;
}

...

C99, Section 5.1.2.2.3, has this to say about returning from {{main()}} \ [[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\]:

If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.

...

Calling _Exit() causes normal program termination to occur. Like the exit() function _Exit() also takes one argument of type int and never returns. However, unlike exit(), whether _Exit() closes open streams, flushes stream buffers ^#1, or deletes temporary files is implementation-defined. Functions registered by atexit() are not executed.

#include <stdlib.h>
/* ... */

if (/* something really bad happened */) {
  _Exit(EXIT_FAILURE);
}

...

As with _Exit(), whether open streams with unwritten buffered data are flushed ^#2, open streams are closed, or temporary files are removed is implementation-defined. Functions registered by atexit() are not executed. (See recommendation ERR06-C. Understand the termination behavior of assert() and abort().)

Summary

The following table summarizes the exit behavior of the program termination functions.

...