[omniORB] omniORBpy Exception Question (and omniidl exception patch).

Bray, Carl cbray@orchestream.com
Tue, 28 Mar 2000 14:01:49 +0100


I tend to agree with Robert.

>From the Python Library Reference it states;

Exception
The root class for exceptions. All built-in exceptions are derived from this
class. All user-defined
exceptions should also be derived from this class, but this is not (yet)
enforced. The str() function,
when applied to an instance of this class (or most derived classes) returns
the string value of the
argument or arguments, or an empty string if no arguments were given to the
constructor. When
used as a sequence, this accesses the arguments given to the constructor
(handy for backward
compatibility with old code). The arguments are also available on the
instance's args attribute,
as a tuple.

However you do not need to call the Exception __init__ method

--
Carl Bray                            http://www.orchestream.com/


-----Original Message-----
From: Robert Sander [mailto:gurubert@gurubert.de]
Sent: 28 March 2000 13:41
To: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] omniORBpy Exception Question (and omniidl
exception patch).


On Tue, Mar 28, 2000 at 10:32:40AM +0100, Duncan Grisby wrote:
> On Monday 27 March, Randy Wiser wrote:
> 
> > Why do the stubs generated by omniidl inherit from class Exception
> > in the standard Python module exceptions.py, but the generated
> > __init__ methods fail to call the __init__ method
> > (exceptions.Exception.__init__) in the class they inherit from?
> 
> There is, in fact, no reason for CORBA.Exception to be derived from
> exceptions.Exception, so I have removed it. It doesn't do any harm to
> inherit from exceptions.Exception, but it would be wrong to call its
> __init__() method, since that would potentially overwrite exception
> data members.

Hm, I think somewhere in the Python reference is stated that every exception
should be inhereted from exceptions.Exception, just because to have a
generic
Superclass that could be excepted.
Overwriting issues are another thing, but I do not think that it is
necessary
to call the constructor of the Superclass in this example.

Greetings
-- 
Robert Sander                                 www.gurubert.de