Handling Exceptions

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

Notes:

The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, 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. Oracle 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

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 Oracle Tuxedo CORBA sample applications do not use the _narrow operation.

Handling System Exceptions

The CORBA C++ client applications in the Oracle 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;
}