[omniORB] Application Exception Hierarchy: How???

[David Morgenlender]

I'm in the process of developing an app consisting of a CORBA server & a =
CORBA
client, using omniORB & Visual C++ 5.  For various reasons, once the app =
is
released it will be very inconvenient to diagnose problems on the server.
Therefore, I'd like the client to generate diagnostic logs.  Ideally, the=
 logs
will show, among other things, details of exceptions thrown by the =
server.  But
I haven't been able to come up with a good way to implement this.

The client app itself will not usually care very much about the details =
of an
exception, only about the fact that an exception has occured.  There will=
 be
times, however, when the app may care about a higher level breakdown, =
e.g. an
app exceptions vs.  a CORBA System Exception vs. a CORBA User Exception. =
 There
will be other times where the app may want to look for a category of app
exceptions.  At other times it may want to look for a specific app =
exception.
In some of these cases, the app may wish to look at information included =
in the
exception.


It's obviously possible to catch CORBA:UserException or =
CORBA:SystemException to
differentiate between these categories of exceptions.  But that still =
leaves a
lot of problems:


1.  Is there any way for the app to determine detailed information about =
CORBA
User & System Exceptions, e.g. which exception has occured, for reporting
purposes, other than by catching each possible exception individually?


2.  The only reasonable way to satisfy the requirements for app =
exceptions is to
generate a hierarchy of app exceptions, e.g. a base class of =
AppException.
Derived from AppException would be AppExceptionCategory1, etc.  Then =
derived
from AppExceptionCategory1 would be AppExceptionCategory1Error1, etc.  =
However,
as far as I can tell, IDL doesn't support derived exceptions.

I could create my own exception class hierarchy, independent of CORBA;  =
then
pass error information as an Any parameter; I would use Any, because the
information is variable length, depending where in the hierarchy the =
exception
lies.  Then the client could cast the parameter into the appropriate =
exception
class & throw it.  But, as far as I can tell, the only way the client can=
 figure
out which class to use would be to have some massive switch statement, =
i.e. this
exception generator must know details of each possible exception;  this =
approach
is too error prone.

In short, I don't see any reasonable way to use a hierarchy of =
application
exceptions.

Can you suggest any good way to implement an exception hierarchy?

If not, can you suggest any good alternative?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Dave Morgenlender
e-mail: dmorgen@alum.mit.edu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D