Creating CORBA Client Applications

Handling Exceptions

This topic describes how CORBA C++ client applications handle CORBA exceptions.

Note: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported in Tuxedo 9.0. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, etc. should only be used:

to help implement/run third party Java ORB libraries, and
for programmer reference only.

Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

CORBA Exception Handling Concepts

CORBA defines the following types of exceptions:

System exceptions, which are general errors, such as running out of memory and communication failures. System exceptions include exceptions raised by the Object Request Broker (ORB). The CORBA specification defines a set of system exceptions that can be raised when errors occur in the processing of a request from a CORBA client application.
User exceptions, which are exceptions triggered by an object, where the exception contains user-defined data. When you define your CORBA object's interface in OMG IDL, you can specify the user exceptions that the object may raise.

The following sections describe how each type of CORBA client application handles exceptions.

CORBA System Exceptions

Table 4-1 lists the CORBA system exceptions.

Table 4-1 CORBA System Exceptions

Exception Name	Description
`BAD_CONTEXT`	An error occurred while processing context objects.
`BAD_INV_ORDER`	Routine invocations are out of order.
`BAD_OPERATION`	Invalid operation.
`BAD_PARAM`	An invalid parameter was passed.
`BAD_TYPECODE`	Invalid typecode.
`COMM_FAILURE`	Communication failure.
`DATA_CONVERSION`	Data conversion error.
`FREE_MEM`	Unable to free memory.
`IMP_LIMIT`	Implementation limit violated.
`INITIALIZE`	ORB initialization failure.
`INTERNAL`	ORB internal error.
`INTF_REPOS`	An error occurred while accessing the Interface Repository.
`INV_FLAG`	Invalid flag was specified.
`INV_IDENT`	Invalid identifier syntax.
`INV_OBJREF`	Invalid object reference was specified.
`MARSHAL`	Error marshaling parameter or result.
`NO_IMPLEMENT`	Operation implementation not available.
`NO_MEMORY`	Dynamic memory allocation failure.
`NO_PERMISSION`	No permission for attempted operation.
`NO_RESOURCES`	Insufficient resources to process request.
`NO_RESPONSE`	Response to request not yet available.
`OBJ_ADAPTER`	Failure detected by object adapter.
`OBJECT_NOT_EXIST`	Object is not available.
`PERSIST_STORE`	Persistent storage failure.
`TRANSIENT`	Transient failure.
`UNKNOWN`	Unknown result.

CORBA C++ Client Applications

Since both system and user exceptions require similar functionality, the SystemException and UserException classes are derived from the common Exception class. When an exception is raised, your CORBA client application can narrow from the Exception class to a specific SystemException or UserException class. The C++ Exception inheritance hierarchy is shown in Figure 4-1.

Figure 4-1 C++ Exception Inheritance Hierarchy

C++ Exception Inheritance Hierarchy

The Exception class provides the following public operations:

copy constructor
destructor
_narrow

The copy constructor and destructor operations automatically manage the storage associated with the exception.

The _narrow operation allows your CORBA client application to catch any type of exception and then determine its type. The exception argument passed to the _narrow operation is a pointer to the base class Exception. The _narrow operation accepts a pointer to any Exception object. If the pointer is of type SystemException, the narrow() operation returns a pointer to the exception. If the pointer is not of type SystemException, the narrow() operation returns a Null pointer.

Unlike the _narrow operation on object references, the _narrow operation on exceptions returns a suitably typed pointer to the same exception argument, not a pointer to a new exception. Therefore, you do not free a pointer returned by the _narrow operation. If the original exception goes out of scope or is destroyed, the pointer returned by the _narrow operation is no longer valid.

Note: The BEA Tuxedo CORBA sample applications do not use the _narrow operation.

Handling System Exceptions

The CORBA C++ client applications in the BEA Tuxedo sample applications use the standard C++ try-catch exception handling mechanism to raise and catch exceptions when error conditions occur, rather than testing status values to detect errors. This exception-handling mechanism is also used to integrate CORBA exceptions into CORBA client applications. In C++, catch clauses are attempted in the order specified, and the first matching handler is called.

The following example from the CORBA C++ client application in the Basic sample application shows printing an exception using the << operator.

Note: Throughout this topic, bold text is used to highlight the exception code within the example.

try{

//Initialize the ORB
CORBA::ORB* orb=CORBA::ORB_init(argc, argv, ORBid);

//Get a Bootstrap Object
Tobj_Bootstrap* bs= new Tobj_Bootstrap(orb, "//host:port");

//Resolve Factory Finder
CORBA::Object_var var_factory_finder_oref = bs->
     resolve_initial_reference("FactoryFinder");
Tobj::FactoryFinder_var var_factory_finder_ref = Tobj::FactoryFinder::_narrow
     (var_factory_finder_oref.in());

catch(CORBA::Exception& e) {
     cerr <<e.get_id() <<end1;
}

User Exceptions

User exceptions are generated from the user-written OMG IDL file in which they are defined. When handling exceptions, the code should first check for system exceptions. System exceptions are predefined by CORBA, and often the application cannot recover from a system exception. For example, system exceptions may signal problems in the network transport or signal internal problems in the ORB. Once you have tested for the system exceptions, test for specific user exceptions.

The following C++ example shows the OMG IDL file that declares the TooManyCredits user exception inside the Registar interface. Note that exceptions can be declared either within a module or within an interface.

exception TooManyCredits
{
    unsigned short maximum_credits;
};

interface Registrar

NotRegisteredList register_for_courses(
    in StudentId                    student,
    in CourseNumberList             courses
) raises (
    TooManyCredits
);

The following C++ code example shows how a TooManyCredits user exception would work within the scope of a transaction for registering for classes:

//Register a student for some course

try {
     pointer_registrar_reference->register_for_courses
         (student_id, course_number_list);

catch (UniversityT::TooManyCredits& e) {
    cout <<"You cannot register for more than"<< e.maximum_credits
    <<"credits."<<end1;
}