BEA Logo BEA BEA Tuxedo Release [Release Number]

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT

 

   BEA Tuxedo Doc Home   |   Creating CORBA Client Applications   |   Previous Topic   |   Next Topic   |   Contents   |   Index

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:

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

 


CORBA System Exceptions

Table 5-1 lists the CORBA system exceptions.

Table 5-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 5-1.

Figure 5-1 C++ Exception Inheritance Hierarchy


 

The Exception class provides the following public operations:

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;
}

 


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.

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

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

Figure 5-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:

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:

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

 

back to top previous page