|
BEA WebLogic Enterprise 4.2 Developer Center | |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
Developing Applications | TABLE OF CONTENTS | PREVIOUS TOPIC | INDEX |
||
This chapter describes how CORBA C++, CORBA Java, and ActiveX client applications handle CORBA exceptions.
CORBA defines the following types of exceptions:
CORBA Exception Handling Concepts
The following sections describe how each type of client application handles exceptions.
Table 7-1 lists the CORBA system exceptions.
Since both system and user exceptions require similar functionality, the
The CORBA System Exceptions
CORBA C++ Client Applications
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

Exception class provides the following public operations:
copy constructor
The The Unlike the
Note:
The University sample applications do not use the The CORBA C++ client 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 WLE client applications. In C++, The following example for a C++ client application shows printing the respositoryId for the exception.
Note:
Throughout this chapter, bold text is used to highlight the exception code within the example.
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 The following C++ code example shows how a
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:
copy constructor and destructor operations automatically manage the storage associated with the exception.
_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.
_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.
_narrow operation.
Handling System Exceptions
catch clauses are attempted in the order specified, and the first matching handler is called.
int main (int arg c, char* arg v [ ])
{
CORBA::ORB_var orb;
try{ //Initialize the ORB}
orb = CORBA::ORB_init (argc, argv);
catch(CORBA::Exception& e) {
cerr <<e.get_id() <<endl;
}
...
} User Exceptions
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 ();
TooManyCreditsTooManyCredits 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."<<endl;}CORBA Java Client Applications
java.lang.RuntimeException.
Figure 7-2 shows the inheritance hierarchy of the Java Exception classes.
The standard OMG IDL system exceptions are mapped to final Java classes that extend
Note:
There are no public constructors for 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 The following Java code example illustrates how to use system exceptions:
User exceptions are mapped to final Java classes that extend 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:
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:
Figure 7-2 Java Exception Inheritance Hierarchy

System Exceptions
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.
org.omg.CORBA.SystemException; only classes that extend it can be instantiated.
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.
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
org.omg.CORBA.UserException and are otherwise mapped like the OMG IDL struct data type, including the generation of Helper and Holder classes.
//Register for Coursestry{ gRegistrarObjRef.register_for_courses(student_id, selected_course_numbers);
}catch(UniversityT.TooManyCredits e){}
System.err.println("TooManyCredits: " +e);
System.exit(1);ActiveX Client Applications
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