Errors: Difference between revisions
pc>Yuron No edit summary |
 W81054ch [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
(No difference)
| |
Revision as of 10:02, 5 August 2019
| Depends on | Libraries • System Calls |
|---|
Error handling is an important – yet often neglected – aspect of any software. However attention here is focused on operating system and related errors.
Sometimes things go ‘wrong’. A specific example might be in a request for some resource: asking for too much memory space, trying to read a file which does not exist, creating more processes than the O.S. limit etc. Such “errors” will be handled by an O.S. and control returned to the application so that it can try to adapt appropriately. In the worst case – if an application cannot continue – it can shut down tidily, closing any open files and releasing resources.
A particular issue arises if the application is using multiple processes; an ‘error’ in one process may need to be
communicated to others. As a simple example, think of an application which may use two communicating processes, each with its own window on a display: if the user decides to shut one window (X) that process should clean itself up but it should also signal is partner so it, too can tidy up and close.
The “tidy up” may include such tasks as unlinking from – and requesting the eventual destruction of – resources such as shared memory; as a shared memory does not belong exclusively to one process the O.S. cannot recover it (unlike private memory) simply because a particular process has terminated. (Failure to recover the memory will lead to a resource leak which is a Bad Thing.
Unix errors
When a Unix system call fails it returns a diagnostic code which (in C) is readable as a global value errno. (The C header <errno.h> also contains definitions of the error codes (Linux).
In addition, a library may return some ‘obvious’ status from the call. For example, if opening a file succeeds then:
| Library call | Success | Failure | errno |
|---|---|---|---|
| open() | a (positive) file descriptor | -1 | errno |
| fopen() | a non-NULL pointer | NULL | errno |
Failures should be caught and handled. Not doing this (e.g. subsequently dereferencing the NULL pointer, above) can make life worse.
Check the relevant man pages for the list of possible errors which a call can return. Ideally these should all be treated sensibly. (At a quick count Linux open() can indicate 21 different types of error, for example.)
exit(<argument>);
A particular form of Unix error is a process exiting. This call does not return but will close any owned file descriptors and allow resources to be recovered. It also sends a signal (SIGCHLD) to its parent and the argument is made available.
A parent process can read its child’s exit status with a wait() call if it wishes. Normally a value of ‘0’ is used to indicate “terminated normally” and other values (often just ‘1’) can indicate an anomalous termination (also a form of error).
If a process terminates with child processes still running, they are 'orphaned’ and inherited by the init process
(a.k.a. “system” in Linux). Thus a systematic way of shutting down multi-process applications could be to first signal to
the parent, then have that signal down the process tree to close down, with each parent waiting until its children have terminated before terminating itself.
