OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
Write functions that propagate exceptions to their callers so that the function does
not modify any persistent process state before raising the exception. A call to the
matching close call is required only if the open_file operation is successful in the
current scope.
If open_file raises an exception, the identifier will not be written, so open_file must
not require that close be called when open_file raises an exception; that is, open_file
should not be part of the TRY clause because that means close is called if open_file
fails, and you cannot close an unopened file.
• Do not place a RETURN or nonlocal GOTO between TRY and ENDTRY.
It is invalid to use RETURN or GOTO, or to leave by any other means, a TRY,
CATCH, CATCH_ALL,orFINALLY block. Special code is generated by the
ENDTRY macro, and it must be executed.
• Use the ANSI C volatile attribute.
Variables that are read or written by exception-handling code must be declared with
the ANSI C volatile attribute. Run your tests with the optimize compiler option to
ensure that the compiler thoroughly tests your exception-handling code.
• Reraise exceptions that are not fully handled.
You need to reraise any exception that you catch, unless your handler performs the
complete recovery action for the error. This rule permits an unhandled exception to
propagate to some final default handler that prints an error message to terminate the
offending thread. (An unhandled exception is an exception for which recovery is
incomplete.)
A corollary of this rule is that CATCH_ALL handlers must reraise the exception
because they may catch any exception, and usually cannot do recovery actions that
are proper for every exception.
Following this convention is important so that you also do not absorb a cancel or
thread-exit request. These are mapped into exceptions so that exception handling
has the full power to handle all exceptional conditions from access violations to
thread exit. (In some applications, it is important to be able to catch these to work
around an erroneously written library package, for example, or to provide a fully
fault-tolerant thread.)
• Declare only static exceptions.
For compatibility with C++, you need to only declare static exceptions.
9.5 DCE Threads Exceptions and Definitions
Table 9-1 lists the DCE Threads exceptions and briefly explains the meaning of each
exception. Exception names beginning with pthread_ are raised as the result of
something happening internal to the DCE Threads facility and are not meant to be raised
by your code. Exceptions beginning with exc_ are generic and belong to the exception
facility, the underlying system, or both. The pthread-specific extensions are listed
followed by the generic extensions, each in alphabetical order.
9− 8 Tandem Computers Incorporated 124245