[Enterprise Extensions only]

IDL exception declarations

IDL specifications can include exception declarations, which define data structures to be returned when an exception occurs during the execution of an operation. A name is associated with each type of exception. Optionally, a struct-like data structure for holding error information can also be associated with an exception. Exceptions are declared as follows:

exception identifier
  {
     member*
  };

The identifier is the name of the exception, and each member has the following form:

type-spec declarators ;

The type-spec is a valid IDL type specification and declarators is a list of identifiers or array declarators, delimited by commas. The members of an exception structure should contain information to help the caller understand the nature of the error. The exception declaration can be treated like a struct definition: whatever you can access in an IDL struct, you can access in an IDL exception. Unlike a struct, an exception can be empty, meaning the exception is just identified by its name.

If an exception is returned as the outcome of an operation, the exception identifier indicates which exception occurred. The values of the members of the exception provide additional information specific to the exception. IDL operation declarations describes how to indicate that a particular operation can raise a particular exception.

The following is an example showing the declaration of a BAD_FLAG exception:

exception BAD_FLAG
{
   long ErrCode; char Reason[80];
};

In addition to user-defined exceptions, there are several predefined exceptions for system run-time errors. The standard exceptions as prescribed by CORBA are subclasses of CORBA::SystemException. These exceptions correspond to standard run-time errors that can occur during the execution of any operation (regardless of the list of exceptions listed in the operation's IDL specification).

Each of the standard exceptions has the same structure: an error code (to designate the subcategory of the exception) and a completion status code. For example, the NO_MEMORY standard exception has the following definition:

enum completion_status 
{
   COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE
};
exception NO_MEMORY 
{ 
   unsigned long minor;
     completion_status completed; 
};

The "completion_status" value indicates whether the operation was never initiated (COMPLETED_NO), if the operation completed its execution prior to the exception (COMPLETED_YES), or if the operation's completion status is indeterminate (COMPLETED_MAYBE).