[omniORB] omniORBpy Exception Question (and omniidlexception patch).
Tres Seaver
tseaver@palladion.com
Wed, 29 Mar 2000 07:28:43 -0600
Duncan Grisby wrote:
>
> Sorry to all the people on the list who don't care about Python. Maybe
> we need an omniORBpy list.
>
> On Tuesday 28 March, Randy Wiser wrote:
>
> > I think I agree with you that CORBA.Exception should inherit from
> > exceptions.Exception (as it does now).
> [...]
>
> Unfortunately, there is a fundamental conflict between the Python
> mapping for CORBA exceptions, and the full use of the
> exceptions.Exception class. exceptions.Exception is defined as:
>
> class Exception:
> """Proposed base class for all exceptions."""
> def __init__(self, *args):
> self.args = args
>
> def __str__(self):
> if not self.args:
> return ''
> elif len(self.args) == 1:
> return str(self.args[0])
> else:
> return str(self.args)
>
> def __getitem__(self, i):
> return self.args[i]
>
> The big problem is the args data member. Suppose I have an exception
> declared in IDL
>
> interface MyException {
> long args;
> };
>
> An instance of this exception will have a data member called args,
> which clashes with args in the exceptions.Exception base class. This
> means that the __str__ and __getitem__ methods won't work.
> CORBA.Exception already overrides the __str__ method; maybe I need to
> provide a __getitem__ method too? Would that solve your (Randy's)
> problem?
>
> Maybe the proper fix is to change the Python mapping to use _args
> instead of args in this case.
I think that is the Right Thing (tm) to do here -- treat the problem just like
any other clashe with the implementation language.
> Alternatively, I could try to convince
> Guido to change exceptions.Exception to call its data member
> __args. Since the args member is documented, I don't imagine he'd be
> keen on that...
"That dog won't hunt", as we say here in Texas. :)
--
=========================================================
Tres Seaver tseaver@digicool.com tseaver@palladion.com