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

Randy Wiser randyw@amc.com
Tue, 28 Mar 2000 11:02:52 -0800


Thanks for the quick response!

At 10:32 AM 03/28/2000 +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.

I thought that using the '__' prefix to instance members was supposed to avoid just these sort of name clashes?  And, I'd be interested in knowing how the patch broke for exceptions with parameters? (see below)

> > I've attached a patch for the omniidl Python back-end (omniORB 3.0
> > or 2.8) which seems to correct this, but I'm curious if it is the
> > 'right thing' to do?
>
>You patch was the wrong thing to do, since it broke for exceptions
>with any data members. The correct thing to do is to remove
>exceptions.Exception from the inheritance hierarchy, but as I say, it
>doesn't actually hurt to have it there.
>
>Thanks for pointing out the strangeness,

At 03:51 PM 03/28/2000 +0100, Duncan Grisby wrote:
>On Tuesday 28 March, Richard Gruet wrote:
>
> > I'd prefer that you do NOT remove the inheritance from class Exception, I
> > have some code that rely on this (but not calling __init__ is OK).
>
>OK, it's back again. :-)
>
>Cheers,
>
>Duncan.

I guess not chaining to __init__ is okay for now (except for some people (like me) who do strange things like pass IDL derived exceptions to standard Python modules, which in turn use the standard exceptions.py, which complains about missing members in the exception, since __init__ was not called :-)

So, we're back where we started?

- Randy