Errors: Difference between revisions
pc>Yuron No edit summary |
 D73083ds [ PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (Fix broken link of errornos to active one) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
-->{{#invoke:Dependencies|add|Libraries,4|System Calls,4}} | -->{{#invoke:Dependencies|add|Libraries,4|System Calls,4}} | ||
<blockquote> | <blockquote> | ||
Error handling is an important – yet often neglected – aspect of | Error handling is an important – yet often neglected – aspect of <em>any</em> software. However attention here is focused on operating system and related errors. | ||
<em>any</em> software. However attention here is focused on operating | |||
system and related errors. | |||
</blockquote> | </blockquote> | ||
Sometimes things go ‘wrong’. A specific example might be | Sometimes things go ‘wrong’. A specific example might be in a request for some resource: asking for too much memory space, | ||
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. | ||
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 | A particular issue arises if the application is using multiple processes; an ‘error’ in one process may need to be | ||
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 (<code>X</code>) that process should clean itself up but it should also [[Unix Signals|signal]] is partner so it, too can tidy up and close. | ||
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 (<code>X</code>) that process | |||
should clean itself up but it should also [[Unix Signals|signal]] is | |||
partner so it, too can tidy up and close. | |||
[[Image:sigterm.png|link=|alt=SIGTERM example]] | [[Image:sigterm.png|link=|alt=SIGTERM example]] | ||
| Line 28: | Line 15: | ||
=== Unix errors === | === Unix errors === | ||
When a Unix [[System Calls|system call]] fails it returns a diagnostic | When a Unix [[System Calls|system call]] fails it returns a diagnostic code which (in C) is readable as a global value <code>errno</code>. (The C header <code><errno.h></code> also contains definitions of the [https://man7.org/linux/man-pages/man3/errno.3.html error codes] (Linux). | ||
code which (in C) is readable as a global value <code>errno</code>. (The C | |||
header <code><errno.h></code> also contains definitions of the [ | |||
In addition, a library may return some ‘obvious’ status | In addition, a library may return some ‘obvious’ status from the call. For example, if opening a file succeeds then: | ||
from the call. For example, if opening a file succeeds then: | |||
{| | {| | ||
! style="text-align:center" |Library call | ! style="text-align:center" |Library call | ||
| Line 50: | Line 34: | ||
| style="text-align:center" |errno | | style="text-align:center" |errno | ||
|} | |} | ||
Failures should be caught and handled. Not doing this | Failures should be caught and handled. Not doing this (e.g. subsequently dereferencing the NULL pointer, above) can make | ||
(e.g. subsequently dereferencing the NULL pointer, above) can make | |||
life worse. | life worse. | ||
Check the relevant [[man]] pages for the list of possible errors | Check the relevant [[man]] pages for the list of possible errors which a call can return. <em>Ideally</em> these should all be treated sensibly. (At a quick count Linux <code>open()</code> can indicate 21 different types of error, for example.) | ||
which a call can return. <em>Ideally</em> these should all be treated | |||
sensibly. | |||
(At a quick count Linux <code>open()</code> can indicate 21 different types of | |||
error, for example.) | |||
==== exit(<argument>); | ==== exit(<argument>); ==== | ||
A particular form of Unix error is a process exiting. This call does | 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 [[Unix Signals|signal]] (<code>SIGCHLD</code>) to its parent and the argument is made available. | ||
not return but will close any owned file descriptors and allow | |||
resources to be recovered. It also sends a [[Unix Signals| signal]] | |||
(<code>SIGCHLD</code>) to its parent and the argument is made available. | |||
A parent process can read its child’s exit status with a <code>wait()</code> call | A parent process can read its child’s exit status with a <code>wait()</code> 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 <em>error</em>). | ||
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 | |||
<em>error</em>). | |||
If a process terminates with child processes still running, they are | If a process terminates with child processes still running, they are 'orphaned’ and inherited by the <code>init</code> process | ||
(a.k.a. “system” in Linux). Thus a systematic way of shutting down multi-process applications could be to first <em>signal</em> to | |||
(a.k.a. “system” in Linux). Thus a systematic way of | the parent, then have that signal down the process tree to close down, with each parent <em>wait</em>ing until its children have terminated before terminating itself. | ||
shutting down multi-process applications could be to first <em>signal</em> to | |||
the parent, then have that signal down the process tree to close down, | |||
with each parent <em>wait</em>ing until its children have terminated before | |||
terminating itself. | |||
---- | ---- | ||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Exceptions}} | {{Category|Exceptions}} | ||
{{Category|User}} | {{Category|User}} | ||
Latest revision as of 15:27, 8 May 2023
| 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.
