[Previous] [Contents] [Next] [IONA Technologies]


Chapter 12
Exception Handling


Contents

12.1 User-Defined Exceptions
12.1.1 The IDL Definitions
12.1.2 The Generated Code
12.2 System Exceptions
12.3 The Client: Handling Exceptions
12.3.1 Handling Specific System Exceptions
12.4 The Server: Throwing an Exception
12.4.1 Operation Completion Status in System Exceptions



In this chapter, we extend the Bank example of Chapter 6, "Programming OrbixWeb using Java" to raise a user-defined exception, show how to throw such exceptions in the server code and how to handle them in the client. We also describe OrbixWeb system-defined exceptions in detail.

Note that OrbixWeb does not require any special handling for exceptions. IDL exceptions are mapped to Java classes which inherit from java.lang.Exception. Therefore, exceptions thrown by a server can be handled by try and catch statements in the normal way.

12.1 User-Defined Exceptions

In this section, we illustrate how to define exceptions in IDL and describe the OrbixWeb Java mapping for such user-defined exceptions.

12.1.1 The IDL Definitions

Continuing with the Bank example, we extend the interface Bank so that the newAccount() operation may raise an exception if the bank is unable or unwilling to create an Account object.

The exception Reject is defined within the Bank interface and it defines a string member which will indicate the reason which caused the Bank to reject the request.

12.1.2 The Generated Code

In compliance with the example presented in Chapter 6, we will assume that the above IDL source file is passed to the OrbixWeb IDL compiler using the following command:

The Java code produced by the IDL compiler will be generated within the idl_demo package.

The Java class generated from the IDL exception definition is:

Note that class Reject (in package idl_demo._Bank) inherits from the OrbixWeb class UserException (in package IE.Iona.Orbix2.CORBA). This OrbixWeb class in turn inherits from CORBAException, which is a direct subclass of java.lang.Exception. It is this inheritance which allows Reject to be thrown and handled as a Java exception.

Since the Reject exception has one member (reason, of type string) a constructor is provided in the generated class, which allows this member to be initialised.

The Java interface for Account is generated as follows:

while the generated interface for Bank is:

Note that the generated method for operation newAccount() includes a throws clause for exception idl_demo.Bank.Reject.

12.2 System Exceptions

The CORBA specification defines a set of system exceptions to which OrbixWeb adds a number of additional exceptions. These system exceptions may be raised during OrbixWeb invocations.

The system exceptions are implemented as a set of Java classes (in the package IE.Iona.Orbix2.CORBA), organised into a class hierarchy: each system exception is a derived class of SystemException (which in turn is a derived class of CORBAException). This allows all system exceptions to be caught in one single Java catch clause.

A client can also handle individual system exceptions in separate catch clauses, as described in section 12.3.1. Each system exception is implemented as a class of the following form:

The full set of system exceptions defined by OrbixWeb are documented in Appendix B, "System Exceptions" of the OrbixWeb Reference Guide. This appendix provides a complete listing of the OrbixWeb system exception classes and gives a brief description of each.

12.3 The Client: Handling Exceptions

A client (or server) which calls an operation that may raise a user exception should handle that exception using an appropriate catch statement. Naturally, a client should also provide handlers for potential system exceptions. Here we show an example client program:

The handler for the idl_demo._Bank.Reject exception outputs an error message and exits the program. The toString() method defined on class SystemException generates a text description of the individual system exception that was raised.

12.3.1 Handling Specific System Exceptions

A client may also provide a handler for a specific system exception. For example, to explicitly handle a COMM_FAILURE exception that might be raised from a call to _bind(), the client could write code as follows:

Note that the handler for a specific system exception must appear before the handler for SystemException. In Java, catch clauses are attempted in the order specified, and the first matching handler is called. Thus, a handler for SystemException would match all system exceptions because of implicit casting (since all system exception classes are derived classes of SystemException).

To handle individual system exceptions as shown in the code fragment above, it is necessary to import the required exceptions from the IE.Iona.Orbix2.CORBA package. As an alternative, the exception classes could be referenced by fully scoped names.

Note that if the programmer simply wishes to know the type of exception that occurred, then the message output by toString() on class SystemException is sufficient. A handler for an individual exception is only required when specific action is to be taken if that exception occurs.

12.4 The Server: Throwing an Exception

All OrbixWeb exceptions inherit from Java class CORBAException, which in turn inherits from java.lang.Exception. Consequently, the rules for throwing OrbixWeb exceptions follow those for throwing standard Java exceptions: a programmer simply throws an object of the exception class.

For example, to throw an exception of IDL type Bank::Reject, a programmer could simply do the following:

We use the automatically generated constructor of class Reject to initialise exception object's reason member with the string "Some reason".

The implementation of the newAccount() operation can now be coded as follows:

12.4.1 Operation Completion Status in System Exceptions

Class SystemException includes the method completed(), which may be of use in some applications. This method returns an int value that indicates how far the operation or attribute call progressed before the exception was raised. The return value must be one of three values defined in the OrbixWeb class CompletionStatus (in package IE.Iona.Orbix2.CORBA). These values are as follows:

CompletionStatus.NO

The system exception was raised before the operation or attribute call began to execute.

CompletionStatus.YES

The system exception was raised after the operation or attribute call completed its execution.

CompletionStatus.MAYBE

It is uncertain whether or not the operation or attribute call started execution, and, if it did, whether or not it completed. For example, the status will be CompletionStatus.MAYBE if a client's host receives no indication of success or failure after transmitting a request to a target object on another host.



[Roadmap] [Introduction] [GS: Applications] [GS: Applets]
[IDL] [Mapping] [Programming OrbixWeb] [Publishing Objects] [Retrieving Objects] [IIOP]
[Running Clients] [Running Servers] [Exceptions] [Inheritance] [Callbacks] [Contexts]
[API Configuration] [TypeCode] [Any] [DII] [IR] [Filters] [Smart Proxies] [Loaders] [Locators]
[Index]