Handling Exceptions

 

This topic describes how CORBA C++, CORBA Java, and ActiveX client applications handle CORBA exceptions.

 

---

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 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 client application handles exceptions.

 

---

CORBA System Exceptions

Table 7-1 lists the CORBA system exceptions.

Table 7-1 CORBA System Exceptions

Exception Name	Description
BAD_CONTEXT	An error occured 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 client application can narrow from the Exception class to a specific SystemException or UserException class. The C++ Exception inheritance hierarchy is shown in Figure 7-1.

Figure 7-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 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 WebLogic Enterprise sample applications do not use the _narrow operation.

Handling System Exceptions

The CORBA C++ client applications in the WebLogic Enterprise 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 WebLogic Enterprise client applications. In C++, catch clauses are attempted in the order specified, and the first matching handler is called.

The following example from the 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;
}

 

---

CORBA Java Client Applications

Note: The information in this section is based on the OMG IDL/Java Language Mapping Specification, orbos/97-03-01. Revised: March 19, 1997.

Java client applications handle exceptions in a similar way to C++ client applications:

• System exceptions inherit from java.lang.RuntimeException.

• User-defined exceptions inherit from java.lang.Exception.

Figure 7-2 shows the inheritance hierarchy of the Java Exception classes.

Figure 7-2 Java Exception Inheritance Hierarchy

System Exceptions

The standard OMG IDL system exceptions are mapped to final Java classes that extend org.omg.CORBA.SystemException and provide access to the OMG IDL major and minor exception code, as well as a string describing the reason for the exception.

Note: There are no public constructors for org.omg.CORBA.SystemException; only classes that extend it can be instantiated.

The Java class name for each standard OMG IDL exception is the same as its OMG IDL name and is declared to be in the org.omg.CORBA package. For example, the CORBA-defined system exception BAD_CONTEXT maps to Java as org.omg.CORBA.BAD_CONTEXT. The default constructor supplies zero for the minor code, COMPLETED_NO for the completion code, and "" for the reason string. There is also a constructor that takes the reason and uses defaults for the other fields, as well as a constructor that requires all three parameters to be specified.

The following Java code example illustrates how to use system exceptions:

try
 {
  //Resolve FactoryFinder
  org.omg.CORBA.Object off = bs.resolve_initial_references
     ("FactoryFinder");
  FactoryFinder ff=FactoryFinderHelper.narrow(off);

  org.omg.CORBA.Object of = FactoryFinder.find_one_factory_by_id
    (UniversityT.RegistrarFactoryHelper.id());
  UniversityT.RegistrarFactory F =   
     UniversityT.RegistrarFactoryHelper.narrow(of);
 
catch (org.omg.CORBA.SystemException e)
   {
        System.err.println("System exception " + e);
        System.exit(1);
}

User Exceptions

User exceptions are mapped to final Java classes that extend org.omg.CORBA.UserException and are otherwise mapped like the OMG IDL struct data type, including the generation of Helper and Holder classes.

If the exception is defined within a nested OMG IDL scope (essentially within an interface), its Java class name is defined within a special scope. Otherwise, its Java class name is defined within the scope of the Java package that corresponds to the exceptions's enclosing OMG IDL module.

The following is an example of a user exception:

//Register for Courses
try{
   gRegistrarObjRef.register_for_courses(student_id, selected_course_numbers);
   
catch(UniversityT.TooManyCredits e)
{
       System.err.println("TooManyCredits: " +e);
       System.exit(1);
}

 

---

ActiveX Client Applications

ActiveX client applications use the Visual Basic error handling model, which allows you to perform special actions when an error occurs, such as jumping to a particular error handling routine. When an exception occurs in an ActiveX client application, the standard Visual Basic error handling works as expected; however, the amount of error information that Visual Basic returns for any exceptions is very limited.

Visual Basic provides additional information about the exception that occurred through the description property of the Visual Basic built-in Error object. When an error occurs, the description string is set to indicate what type of error occurred. The object returns a predefined data type for the exceptions. User exceptions are named to distinguish between them.

When using the Visual Basic error handling model, the description string describes the following:

• Whether the exception was a user or a system exception

• The name of the exception

• Whether or not the operation completed before the exception occurred

The Visual Basic error handling model cannot return exception-specific information, such as the user data of a user exception.

To compensate for this shortcoming, ActiveX views of CORBA objects have an additional optional exception return parameter that returns a user exception. When you supply the optional exception object, no Visual Basic exception is triggered. Instead, the return parameter returns the exception information.

If an exception occurs, the return parameter contains an object to get the data from the exception. This object is similar to a structure pseudo-object, with properties for each value. To determine the type of exception, use the exception object properties EX_majorCode or EX_minorCode. The EX_majorCode object property has three possible values:

• 0 when no exception occurred

• 1 when a system exception occurred

• 2 when a user exception occurred

The following is an example of Visual Basic code that handles exceptions:

Dim exceptType As ExceptionType
Dim exceptInfo As DIForeignException

Set exceptInfo = Exc
exceptType = exceptInfo.EX_majorCode

Select Case exceptType

     Case NO_EXCEPTION

            msg = "No Exception" & vbCrLf

            MsgBox msg

     Case SYSTEM_EXCEPTION

            'For a system exception, the returned variant supports the
            'minorCode and completionStatus properties.

            Dim minorCode As Long
            Dim completionStatus As CORBA_CompletionStatus
            Dim completionMsg As String

            minorCode = exceptInfo.EX_minorCode
            completionStatus = exceptInfo.EX_completionStatus
            Select Case completionStatus
                Case COMPLETION_NO
                     completionMsg = "No"
                Case COMPLETION_YES
                     completionMsg = "Yes"
                Case COMPLETION_MAYBE
                     completionMsg = "Maybe"
            End Select

            msg = "System Exception" & vbCrLf
            msg = msg & "    Minor Code = " & minorCode & vbCrLf
            msg = msg & "    Completion Status = " & completionMsg & vbCrLf

            MsgBox msg

        Case USER_EXCEPTION

            'If it is a user exception, the returned variant supports
            'the properties for the defined user exceptions.

            msg = "User Exception" & vbCrLf
            msg = msg & "    Exception: " & exceptInfo.INSTANCE_repositoryId & 
            vbCrLf
            MsgBox msg

        End Select