[omniORB] omniORBpy Exception Question (and omniidlexception patch).

[Richard Gruet]

Randy,

It's not illogical that  CORBA exceptions inherit from class exceptions.Exception in the Python mapping, since this is the recommended thing to do in all the manuals (except for the deprecated old string exceptions).
But oddly enough, in Python you may also raise (and catch with an except) an instance from a class not derived from Exception! I must confess that I don't clearly see the rationale behind this (ask Guido?).
In my opinion, CORBA.Exception should therefore inherit from exceptions.Exception, but ONTH, your arguments look correct too, and the new point is: is it mandatory that an exception derived from exceptions.Exception call Exception.__init__ ? I often omit that, and so far that was harmless. Anyway,
calling Exception.__init__ should be reserved to the derived (CORBA) exception's __init__ method, not to the final user of the exception. And furthermore it should be done as the first action performed, before any direct initialization; this way, no data members can be overwritten in the derived class
(but it can occur in exceptions.Exception!)

I think that I'm gonna take some aspirin now ;-)
Cheers,

Richard Gruet

Randy Wiser wrote:

> 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