OSF DCE Application Development Guide--Core Components

Using the DCE Threads Exception-Returning Interface
9.4 Rules and Conventions for Modular Use of Exceptions
The following rules ensure that exceptions are used in a modular way so that
independent software components can be written without requiring knowledge of each
other:
• Use unique names for exceptions.
A naming convention makes sure that the names for exceptions that are declared
EXTERN from different modules do not clash. The following convention is
recommended:
<facility-prefix>_<error_name>_e
For example, pthread_cancel_e.
• Avoid putting code in a TRY routine that belongs before it.
The TRY only guards statements for which the statements in the FINALLY,
CATCH,orCATCH_ALL clauses are always valid.
A common misuse of TRY is to put code in the try_block that needs to be placed
before TRY. An example of this misuse is as follows:
TRY
handle = open_file (file_name);
/* Statements that may raise an exception here */
FINALLY
close (handle);
ENDTRY
The preceding FINALLY code assumes that no exception is raised by open_file.
This is because the code accesses an invalid identifier in the FINALLY part if
open_file is modified to raise an exception. The preceding example needs to be
rewritten as follows:
handle = open_file (file_name);
TRY
{
/* Statements that may raise an exception here */
}
FINALLY
close (handle);
ENDTRY
The code that opens the file belongs prior to TRY, and the code that closes the file
belongs in the FINALLY statement. (If open_file raises exceptions, it may need a
separate try_block.)
• Raise exceptions to their proper scope.
124245 Tandem Computers Incorporated 9−7