[omniORB] Exceptions in constructors

David Hyde davidh@cavendish.co.uk
Fri, 30 Nov 2001 15:19:51 -0000


As usual you were spot on.  Humblest apologies if I implied that the fault
was with OmniORB and not with myself.

Thanks alot.

David


> -----Original Message-----
> From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> Sent: 29 November 2001 10:11
> To: David Hyde
> Cc: OmniOrb mailing list (E-mail)
> Subject: Re: [omniORB] Exceptions in constructors 
> 
> 
> On Wednesday 28 November, David Hyde wrote:
> 
> > A CORBA object that I am working on is written in such a 
> way that the
> > constructor is liable to throw an exception in certain 
> circumstances.  (This
> > is legacy code that I avoid making fundamental 
> architectural changes to
> > unless there is a good reason).  I have converted this code 
> from using a
> > proprietry ORB to use OmniORB and it used to work.
> 
> [...]
> > I've a feeling that I am going to have to rewrite the code 
> so that the
> > constructor doesn't throw an exception, but is this 
> right???  Presumably the
> > ORB thinks that it has a reference to an object even though 
> it hasn't been
> > activated in the POA and it is crashing when it is 
> erroneously trying to
> > destroy it.  What happens if an exception that is out of my 
> control is
> > called while I'm in my constructor?  Do I have to put try - 
> catches in all
> > of my constructors?
> 
> The problem is that the POA thinks the object _has_ been activated. It
> is therefore trying to deactivate it, which involves accessing a data
> member inherited from omniServant. Since the object doesn't actually
> exist, it understandably blows up.
> 
> So, the question is why the POA thinks the object was successfully
> activated. I suspect your constructor calls _this(), which implicitly
> activates the object, before the exception is thrown. That way, the
> object is never fully constructed, but it finds its way into the POA's
> active object map. The solution to that is to avoid activating the
> object in its constructor.
> 
> If that isn't the problem, can you post a minimal example program that
> exhibits the problem?
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
>