EXAMPLE: TREATING ERRORS AS EXCEPTIONS
a maximum number,
, which is currently
defined to be 15. This structure should be accessed using
Note that it is not possible to raise an exception in another process. Under
very limited circumstances, however, console control handlers, described at the
end of this chapter and in Chapter 6, can be used for this purpose.
Example: Treating Errors as Exceptions
Previous examples use to process system call and other errors. The
function terminates the process when the programmer indi cates that the error is
fatal. This approach, however, prevents an orderly shutdown, and it also prevents
program continua tion after recovering from an error. For example, the program
may have created temporary files that should be
deleted, or the program may sim-
ply proceed to do other work after abandoning the failed task.
other limitations, including the following.
• A fatal error shuts down the entire process when only a single thread
(Chapter 7) should terminate.
•You may wi sh to continue program execution rather than terminate the
•Synchronizati on resources (Chapter 8), such as mutexes, will not be released
in many circumstances.
les will be closed by a terminati ng process (but not by a termina ting
thread), but it is necessary to address the other deficiencies.
The solution is to write a new function,
. This function
(developed in Chapter 2) with a nonfatal code in order to
generate the error message. Next, on a fa tal error, it will raise an exception. The
system will use an exception handler from the calling try block, so the exception
may not actually be fatal if the handler allows the program to recov
augments normal defensive programming techniques, previ-
ously limited to
. Once an error is detected, the exception handler
allows the program to recover and continue after the error. Program 4–2
illustrates thi s capability.
Program 4–1 shows the function. It is in the same source module as
, so the definitions and include files are omitted.
CHAPTER 4 EXCEPTION HANDLING
Program 4–1 Exception Reporting Function
is used in sev eral subsequent examples.
The UNIX signal model is significantly different from SEH. Signals can be missed
or ignored, and the flow is different. Nonetheless, there are points of comparison.
UNIX signal handling is largely supported through the C library, which is also
available in a limited i
mplementation under Windows. In many cases, Windows
programs can use console control handlers, which are described near the end of
this cha pter, in place of signals.
Some signals correspond to Windows exceptions.
Here is the limited signal-to-exception correspondence:
• —Seven distinct floating-point exceptions, such as
• and —User-defined exceptions
The C library
function corresponds to .
Windows will not generate
, , or , although can
generate one of them. Windows does not support
function ( is not in the Standard C library), which can send a
signal to another process, is comparable to the Windows function
(Chapter 6). In the limited case of , Windows has
and , allowing one process (or thread) to
“kill” another, although these functions should be used with care (see Chapters 6