Issue 3246: UnknownUserException and stubs (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the spec currently says (page 1-101): Request invocations made through the DII may result in user-defined exceptions that cannot be fully represented in the calling program because the specific exception type was not known at compile-time. The mapping provides the UnknownUserException so that such exceptions can be represented in the calling process: [...] Here is a code snippet for the DII: req->invoke(); if (req->env()->exception()) { // Got an exception CORBA::Exception * ep = req->env()->exception(); // ... } The para on page 1-101, by implication, says that: - If there are concrete C++ types available in the caller that can represent the user exception, a real user exception is instantiated and the pointer returned by exception() points at the concrete user exception instance. - If there is no concrete C++ type available in the caller for a user exception, the pointer returned by exception() points at an instance of UnknownUserException. It's not as clearly spelled out as this, but it can be implied from the words on page 1-101. This is bad. For one, it implies "action at a distance". For example, linking the stubs for a user exception into a completely unrelated part of the same binary (possibly via a library) would change the behavior of the above DII call. Further, to make this behavior happen would require some form of global initialization data structure. In effect, there would have to be something that would let the ORB know (globally) for which user exceptions stub code is linked in. We rejected the need for global data recently in another context (for the proposed extraction operator for user exceptions). For the same reason, we should reject this here and mandate that, if I use the DII, *all* user exceptions are *always* returned as UnknownUserException. Resolution: Revised Text: Actions taken: January 25, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 25 Jan 2000 16:22:26 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: UnknownUserException and stubs Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ]>f!!HfI!!"l8e9fb4!! Hi, the spec currently says (page 1-101): Request invocations made through the DII may result in user-defined exceptions that cannot be fully represented in the calling program because the specific exception type was not known at compile-time. The mapping provides the UnknownUserException so that such exceptions can be represented in the calling process: [...] Here is a code snippet for the DII: req->invoke(); if (req->env()->exception()) { // Got an exception CORBA::Exception * ep = req->env()->exception(); // ... } The para on page 1-101, by implication, says that: - If there are concrete C++ types available in the caller that can represent the user exception, a real user exception is instantiated and the pointer returned by exception() points at the concrete user exception instance. - If there is no concrete C++ type available in the caller for a user exception, the pointer returned by exception() points at an instance of UnknownUserException. It's not as clearly spelled out as this, but it can be implied from the words on page 1-101. This is bad. For one, it implies "action at a distance". For example, linking the stubs for a user exception into a completely unrelated part of the same binary (possibly via a library) would change the behavior of the above DII call. Further, to make this behavior happen would require some form of global initialization data structure. In effect, there would have to be something that would let the ORB know (globally) for which user exceptions stub code is linked in. We rejected the need for global data recently in another context (for the proposed extraction operator for user exceptions). For the same reason, we should reject this here and mandate that, if I use the DII, *all* user exceptions are *always* returned as UnknownUserException. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <388E230A.38488DC3@floorboard.com> Date: Tue, 25 Jan 2000 14:26:18 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: C++ Revision Task Force CC: issues@omg.org Subject: Re: UnknownUserException and stubs References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -IPe9_Kid9C(Ge9`bp!! Michi Henning wrote: > the spec currently says (page 1-101): > > Request invocations made through the DII may result in > user-defined exceptions that cannot be fully represented > in the calling program because the specific exception type > was not known at compile-time. The mapping provides the > UnknownUserException so that such exceptions can be > represented > in the calling process: [...] > > Here is a code snippet for the DII: > > req->invoke(); > if (req->env()->exception()) { > // Got an exception > CORBA::Exception * ep = req->env()->exception(); > // ... > } > > The para on page 1-101, by implication, says that: > > - If there are concrete C++ types available in the caller > that > can represent the user exception, a real user exception is > instantiated and the pointer returned by exception() > points > at the concrete user exception instance. > > - If there is no concrete C++ type available in the caller > for > a user exception, the pointer returned by exception() > points > at an instance of UnknownUserException. > > It's not as clearly spelled out as this, but it can be implied from > the > words on page 1-101. > > This is bad. For one, it implies "action at a distance". For > example, > linking the stubs for a user exception into a completely unrelated > part of the same binary (possibly via a library) would change > the behavior of the above DII call. Further, to make this behavior > happen would require some form of global initialization data > structure. > In effect, there would have to be something that would let the ORB > know (globally) for which user exceptions stub code is linked in. I have sympathy for the "action at a distance" problem, since the only obvious way to reliably implement this is global static constructed data, which is "evil". > We rejected the need for global data recently in another context (for > the proposed extraction operator for user exceptions). For the same reason, > we should reject this here and mandate that, if I use the DII, *all* user > exceptions are *always* returned as UnknownUserException. However, I don't support this proposal as it stands. You are trading the potential of broken code (linking in a new library that suddenly transforms an UnknownUserException into a known one) into definite broken code in the case of code that is already written and deployed that expects known exceptions raised form the DII to not be in the UnknownUserException form. Perhaps adding a new operation to Evironment that gets the exception as an Any would work, yet not break backwards compatibility? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 26 Jan 2000 10:09:52 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: UnknownUserException and stubs In-Reply-To: <388E230A.38488DC3@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: YOf!!7hA!! I have sympathy for the "action at a distance" problem, since the only > obvious way to reliably implement this is global static constructed > data, which is "evil". > > > We rejected the need for global data recently in another context (for > > the proposed extraction operator for user exceptions). For the same reason, > > we should reject this here and mandate that, if I use the DII, *all* user > > exceptions are *always* returned as UnknownUserException. > > However, I don't support this proposal as it stands. You are trading > the potential of broken code (linking in a new library that suddenly > transforms an UnknownUserException into a known one) into definite > broken code in the case of code that is already written and deployed > that expects known exceptions raised form the DII to not be in the > UnknownUserException form. Well, turns out that ORBacus has always raised UnknownUserException. And, as far as I can tell, that is a compliant implementation of the current spec. That's because there are no words that state definitely one way or the other that you must instantiate the actual user exception if the stubs are linked in. As I said in the original issue, the spec is at best suggestive of instantiating the actual user exception, not definitive. And, as you say above, both the global data and the action at a distance are bad... I'm not arguing like this to avoid changing ORBacus -- we could change it. However, I honestly believe that instantiating the concrete user exception merely because the stubs are linked in somewhere is wrong. I'm trying to get rid of what I believe is a bug -- I'm not trying to be obstinate or push a hidden agenda. (And no, I'm not implying that you accused me of that; I just wanted to make clear where I'm coming from ;-) > Perhaps adding a new operation to Evironment that gets the exception as > an Any would work, yet not break backwards compatibility? I don't think we have any compatibility as is. If I take code written for ORB X and use it on ORB Y, it may not behave as expected because one ORB might use UnknownUserException and the other ORB might use the actual exception. Adding a new operation to Environment won't help solve that particular problem, I think. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <388E5E91.B4BAA3DC@floorboard.com> Date: Tue, 25 Jan 2000 18:40:17 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: UnknownUserException and stubs References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JjJe9[aQ!!7,%!!\Ad!! Michi Henning wrote: > Well, turns out that ORBacus has always raised UnknownUserException. > And, as far as I can tell, that is a compliant implementation > of the current spec. That's because there are no words that state > definitely > one way or the other that you must instantiate the actual user > exception > if the stubs are linked in. As I said in the original issue, the > spec > is at best suggestive of instantiating the actual user exception, > not > definitive. And, as you say above, both the global data and the > action > at a distance are bad... I did some checking and found out that TAO does the same thing. I guess it is time for a survey to find out what other implementations do... > I'm not arguing like this to avoid changing ORBacus -- we could change it. > However, I honestly believe that instantiating the concrete user exception > merely because the stubs are linked in somewhere is wrong. I'm trying > to get rid of what I believe is a bug -- I'm not trying to be obstinate > or push a hidden agenda. (And no, I'm not implying that you accused me > of that; I just wanted to make clear where I'm coming from ;-) > > > Perhaps adding a new operation to Evironment that gets the exception as > > an Any would work, yet not break backwards compatibility? > > I don't think we have any compatibility as is. If I take code written > for ORB X and use it on ORB Y, it may not behave as expected because one > ORB might use UnknownUserException and the other ORB might use the actual > exception. > > Adding a new operation to Environment won't help solve that particular > problem, I think. True, if we find out that a significant class of ORBs do it differently than another significant class. Another reason I am leary of the change is that it busts a useful code idiom. I can't use the C++ catch statement to quickly separate exception types that may be raised via the DII. All that is left is linear probing with any extractors, or else switching on the RepositoryId--either one is significantly more painful. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 Jan 2000 07:52:46 -0500 To: Jonathan Biggar From: Steve Vinoski Subject: Re: UnknownUserException and stubs Cc: C++ Revision Task Force In-Reply-To: <388E5E91.B4BAA3DC@floorboard.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: Z=Ke9,eVd9B"Y!!IL\d9 At 06:40 PM 1/25/00 -0800, Jonathan Biggar wrote: >Michi Henning wrote: >> Well, turns out that ORBacus has always raised UnknownUserException. >> And, as far as I can tell, that is a compliant implementation >> of the current spec. That's because there are no words that state definitely >> one way or the other that you must instantiate the actual user exception >> if the stubs are linked in. As I said in the original issue, the spec >> is at best suggestive of instantiating the actual user exception, not >> definitive. And, as you say above, both the global data and the action >> at a distance are bad... > >I did some checking and found out that TAO does the same thing. I guess >it is time for a survey to find out what other implementations do... My current ORB, Orbix 2000, and my previous ORB, HP ORB Plus, always raise UnknownUserException. And yes, the spec allows that implementation -- I made sure of that when we introduced it because I knew I didn't want to be trying to dynamically link unmarshaling code into the DII somewhere. On that note, do we really need to do anything about this? Applications have to be able to handle UnknownUserException as well as the operation-specific exceptions, and that's that. If some DII implementations can return the specific exceptions for a given operation, then that's fine. --steve From: Paul Kyzivat To: "'Michi Henning'" , Jonathan Biggar Cc: C++ Revision Task Force Subject: RE: UnknownUserException and stubs Date: Wed, 26 Jan 2000 08:50:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &i?e9-~$e9(&[d9Y_8e9 I wasn't there when the binding was defined, but it seems to me that the choice of name implied that some user exceptions were expected to be known. If UnknownUserException should always be returned by the ORB in this context, then its name is wrong. It isn't always an *unknown* user exception. Perhaps it should be called AnyUserException, or SomeUserException. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, January 25, 2000 7:10 PM > To: Jonathan Biggar > Cc: C++ Revision Task Force > Subject: Re: UnknownUserException and stubs > > > On Tue, 25 Jan 2000, Jonathan Biggar wrote: > > > I have sympathy for the "action at a distance" problem, > since the only > > obvious way to reliably implement this is global static > constructed > > data, which is "evil". > > > > > We rejected the need for global data recently in another > context (for > > > the proposed extraction operator for user exceptions). > For the same reason, > > > we should reject this here and mandate that, if I use the > DII, *all* user > > > exceptions are *always* returned as UnknownUserException. > > > > However, I don't support this proposal as it stands. You > are trading > > the potential of broken code (linking in a new library that > suddenly > > transforms an UnknownUserException into a known one) into definite > > broken code in the case of code that is already written and > deployed > > that expects known exceptions raised form the DII to not be in the > > UnknownUserException form. > > Well, turns out that ORBacus has always raised UnknownUserException. > And, as far as I can tell, that is a compliant implementation > of the current spec. That's because there are no words that > state definitely > one way or the other that you must instantiate the actual > user exception > if the stubs are linked in. As I said in the original issue, the > spec > is at best suggestive of instantiating the actual user exception, > not > definitive. And, as you say above, both the global data and the > action > at a distance are bad... > > I'm not arguing like this to avoid changing ORBacus -- we > could change it. > However, I honestly believe that instantiating the concrete > user exception > merely because the stubs are linked in somewhere is wrong. I'm > trying > to get rid of what I believe is a bug -- I'm not trying to be > obstinate > or push a hidden agenda. (And no, I'm not implying that you accused > me > of that; I just wanted to make clear where I'm coming from ;-) > > > Perhaps adding a new operation to Evironment that gets the > exception as > > an Any would work, yet not break backwards compatibility? > > I don't think we have any compatibility as is. If I take code > written > for ORB X and use it on ORB Y, it may not behave as expected > because one > ORB might use UnknownUserException and the other ORB might > use the actual > exception. > > Adding a new operation to Environment won't help solve that > particular > problem, I think. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Thu, 27 Jan 2000 06:21:48 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: UnknownUserException and stubs In-Reply-To: <388E5E91.B4BAA3DC@floorboard.com> Message-ID: > Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Fbpd9FmVd9c Michi Henning wrote: > > Well, turns out that ORBacus has always raised > UnknownUserException. > > And, as far as I can tell, that is a compliant implementation > > of the current spec. That's because there are no words that state > definitely > > one way or the other that you must instantiate the actual user > exception > > if the stubs are linked in. As I said in the original issue, the > spec > > is at best suggestive of instantiating the actual user exception, > not > > definitive. And, as you say above, both the global data and the > action > > at a distance are bad... > > I did some checking and found out that TAO does the same thing. I > guess > it is time for a survey to find out what other implementations do... I happen to know about MICO, which always returns UnknownUserException. > > I don't think we have any compatibility as is. If I take code written > > for ORB X and use it on ORB Y, it may not behave as expected because one > > ORB might use UnknownUserException and the other ORB might use the actual > > exception. > > > > Adding a new operation to Environment won't help solve that particular > > problem, I think. > > True, if we find out that a significant class of ORBs do it differently > than another significant class. > > Another reason I am leary of the change is that it busts a useful code > idiom. I can't use the C++ catch statement to quickly separate > exception types that may be raised via the DII. All that is left is > linear probing with any extractors, or else switching on the > RepositoryId--either one is significantly more painful. The price of the DII... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 27 Jan 2000 06:50:20 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: Jonathan Biggar , C++ Revision Task Force Subject: Re: UnknownUserException and stubs In-Reply-To: <4.1.20000126074843.01961520@mail.boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c;N!!Bj&"!?,g!![?Fe9 Status: U On Wed, 26 Jan 2000, Steve Vinoski wrote: > My current ORB, Orbix 2000, and my previous ORB, HP ORB Plus, always raise > UnknownUserException. And yes, the spec allows that implementation -- I > made sure of that when we introduced it because I knew I didn't want to be > trying to dynamically link unmarshaling code into the DII somewhere. > > On that note, do we really need to do anything about this? Applications > have to be able to handle UnknownUserException as well as the > operation-specific exceptions, and that's that. If some DII implementations > can return the specific exceptions for a given operation, then that's fine. I think we do need to do something. The problem I see is that, otherwise, we get non-portable code. For example, on one ORB, I write the code such that it expects UnknownUserException and then pulls out the exact user exception explicitly. Then, when I move the code to another ORB, I don't get UnknownUserException and the code does unknown things... Cheers, Michi. Date: Thu, 27 Jan 2000 06:51:47 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: Jonathan Biggar , C++ Revision Task Force Subject: RE: UnknownUserException and stubs In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140313@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~MS!!AKg!!`7;e9hMl!! Status: U On Wed, 26 Jan 2000, Paul Kyzivat wrote: > I wasn't there when the binding was defined, but it seems to me that the > choice of name implied that some user exceptions were expected to be known. > > If UnknownUserException should always be returned by the ORB in this > context, then its name is wrong. It isn't always an *unknown* user > exception. Perhaps it should be called AnyUserException, or > SomeUserException. Yes, the naming is maybe a little unfortunate. However, I don't think we should change that. I'm more concerned about the ill-defined semantics right now. I can live with a sub-optimal name if I at least can rely on defined behavior... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 Jan 2000 16:04:41 -0500 To: Jonathan Biggar From: Steve Vinoski Subject: Re: UnknownUserException and stubs Cc: C++ Revision Task Force In-Reply-To: <388F3C4E.5CF34297@floorboard.com> References: <4.1.20000126074843.01961520@mail.boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: k!:!!MKi!!e<"!!'+G!! Status: U At 10:26 AM 1/26/00 -0800, Jonathan Biggar wrote: >I don't agree. Having to catch both the real exception type and >UnknownUserException containing that type in all of my DII code to be >portable is a lot of unnecessary work. We need to settle on one or the >other It is really all that much work, in practice? How many possible user exceptions are there on any given operation? Two? Four? Philippe Merle, the main author of CORBAscript which is entirely DII-driven, has been porting to Orbix 2000 lately and has been asking Michi and me lots of DII-related questions, and he's never said a word to me about this issue. I would think that if anyone was deeply affected by this issue in practice, he would be at the front of the line. >although I will be somewhat disappointed if we can't come up with >an efficient mechanism to allow an exception returned by the DII to be >thrown as the real exception type. Don't see how we're gonna come up with anything agreeable in this space. You either have the compile-time info, or you don't. Avoiding static ctors is a must. So you would have to come up with some way of having the application pass some kind of unmarshaling info into the DII, sort of like ExceptionLists containing not TypeCodes but instead containing some kind of objects that encapsulate the unmarshaling code for each possible exception. And there you're getting very much into ORB implementation territory. This is of course easily done in Java because of their portable stubs. Orbix 2000 for C++ could also easily do this, but I don't know about other C++ ORBs. --steve From: Paul Kyzivat To: C++ Revision Task Force Subject: RE: UnknownUserException and stubs Date: Wed, 26 Jan 2000 16:14:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \(8!!]O`d9:o-!!H=;e9 My logic was that the name suggests the original *intent*. If that was the case, then we are also making a change that violates that original intent. Of course we are free to do that if, after consideration, we decide that is the right thing to do. But it is a bigger change than fixing an oversight. I can see pros and cons either way. However I think permitting a "known" exception to be reported either way has the disadvantages of both and the advantages of neither. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Wednesday, January 26, 2000 3:52 PM > To: Paul Kyzivat > Cc: Jonathan Biggar; C++ Revision Task Force > Subject: RE: UnknownUserException and stubs > > > On Wed, 26 Jan 2000, Paul Kyzivat wrote: > > > I wasn't there when the binding was defined, but it seems > to me that the > > choice of name implied that some user exceptions were > expected to be known. > > > > If UnknownUserException should always be returned by the ORB in > this > > context, then its name is wrong. It isn't always an *unknown* user > > exception. Perhaps it should be called AnyUserException, or > > SomeUserException. > > Yes, the naming is maybe a little unfortunate. However, I > don't think we > should change that. I'm more concerned about the ill-defined > semantics right > now. I can live with a sub-optimal name if I at least can > rely on defined > behavior... > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Thu, 27 Jan 2000 07:21:52 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Steve Vinoski , C++ Revision Task Force Subject: Re: UnknownUserException and stubs In-Reply-To: <388F3C4E.5CF34297@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: dKCe9I4id90(g!!o3Ce9 Status: U On Wed, 26 Jan 2000, Jonathan Biggar wrote: > I don't agree. Having to catch both the real exception type and > UnknownUserException containing that type in all of my DII code to > be > portable is a lot of unnecessary work. Yes, that's my feeling too. > We need to settle on one or the > other, although I will be somewhat disappointed if we can't come up > with > an efficient mechanism to allow an exception returned by the DII to > be > thrown as the real exception type. Well, I don't see how this could be achieved without the ORB building some global table of the user exceptions that are linked in. But that requires global constructors... Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 Jan 2000 16:23:32 -0500 To: Michi Henning From: Steve Vinoski Subject: Re: UnknownUserException and stubs Cc: C++ Revision Task Force In-Reply-To: References: <4.1.20000126074843.01961520@mail.boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: @l0!!eQBe9DGD!!>`od9 At 06:50 AM 1/27/00 +1000, Michi Henning wrote: >On Wed, 26 Jan 2000, Steve Vinoski wrote: > >> My current ORB, Orbix 2000, and my previous ORB, HP ORB Plus, always raise >> UnknownUserException. And yes, the spec allows that implementation -- I >> made sure of that when we introduced it because I knew I didn't want to be >> trying to dynamically link unmarshaling code into the DII somewhere. >> >> On that note, do we really need to do anything about this? Applications >> have to be able to handle UnknownUserException as well as the >> operation-specific exceptions, and that's that. If some DII implementations >> can return the specific exceptions for a given operation, then that's fine. > >I think we do need to do something. The problem I see is that, otherwise, >we get non-portable code. For example, on one ORB, I write the code >such that it expects UnknownUserException and then pulls out the exact >user exception explicitly. Then, when I move the code to another ORB, I >don't get UnknownUserException and the code does unknown things... The reason I don't think we need to do anything is that as things currently stand, portable code has to handle both styles. req->invoke(); CORBA::Exception *e = req->env()->exception(); if (e != 0) { try { CORBA::UnknownUserException* uuexc = CORBA::UnknownUserException::_downcast(e); if (uuexc != 0) throw *uuexc; else { CORBA::UnknownUserException ue; ue.exception() <<= *e; throw ue; } } catch (const UnknownUserException& exc) { // all exception handling code here } } --steve Sender: jbiggar@corvette.floorboard.com Message-ID: <388F69C4.452E0BD4@floorboard.com> Date: Wed, 26 Jan 2000 13:40:20 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Steve Vinoski , C++ Revision Task Force Subject: Re: UnknownUserException and stubs References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :``!!`ej!!FW=!!$Y+e9 Michi Henning wrote: > > On Wed, 26 Jan 2000, Jonathan Biggar wrote: > > > I don't agree. Having to catch both the real exception type and > > UnknownUserException containing that type in all of my DII code to > be > > portable is a lot of unnecessary work. > > Yes, that's my feeling too. > > > We need to settle on one or the > > other, although I will be somewhat disappointed if we can't come > up with > > an efficient mechanism to allow an exception returned by the DII > to be > > thrown as the real exception type. > > Well, I don't see how this could be achieved without the ORB > building > some global table of the user exceptions that are linked in. But > that > requires global constructors... Perhaps we could have exception factory classes with an explicit registration mechanism? If a factory was registered, the DII uses that to construct the real exception, rather than using UknownUserException. In fact, we don't need factory classes at all, just provide a new static member function in each exception class: // IDL exception MyException { }; // C++ class MyException : public CORBA::UserException { ... public: static Exception *_create_for_unmarshal(); ... }; and add a new ORB operation: namespace CORBA { ... class ORB { ... typedef Exception *(*ExceptionFactory)(); void register_exception_factory(const char *repository_id, ExceptionFactory e_factory); ... }; ... }; This does have an action at a distance downside, in that linking with a new library could still cause UnknownUserExceptions to mutate into normal user exceptions. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 27 Jan 2000 08:52:10 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: Jonathan Biggar , C++ Revision Task Force Subject: Re: UnknownUserException and stubs In-Reply-To: <4.1.20000126152234.0197f640@mail.boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 7lpd9B71e9X/6!!P#8e9 On Wed, 26 Jan 2000, Steve Vinoski wrote: > At 10:26 AM 1/26/00 -0800, Jonathan Biggar wrote: > >I don't agree. Having to catch both the real exception type and > >UnknownUserException containing that type in all of my DII code to > be > >portable is a lot of unnecessary work. We need to settle on one or > the > >other > > It is really all that much work, in practice? How many possible user > exceptions are there on any given operation? Two? Four? Well, there are some interfaces that are rather generous with user exceptions. For example, the trader IDL contains operations that raise eight exceptions (add_type), nine exceptions (export), eleven exceptions (modify), ten exceptions (query), etc, etc. The number of user exceptions per operation is very much a matter of interface style; I don't think we can assume that the number will always be low (especially when an OMG service already provides a counter-example). > Philippe Merle, the main author of CORBAscript which is entirely > DII-driven, has been porting to Orbix 2000 lately and has been > asking Michi > and me lots of DII-related questions, and he's never said a word to > me > about this issue. I would think that if anyone was deeply affected > by this > issue in practice, he would be at the front of the line. Well, I'd hate to have to write DII code that always has to check for both UnknownUserException as well as all the others. I think that's another argument in favour of always instantiating UnknownUserException. That way, I can pull out the exception, give it to a helper function that pulls out the real exception, and then rethrows it (if I have the stubs linked in). I can then use a normal catch handler to deal with it. This would be uniform as far as the API is concerned, instead of basically having no idea what will happen at run time and, worse, having the behavior change potentially if I link against a different library. > >although I will be somewhat disappointed if we can't come up with > >an efficient mechanism to allow an exception returned by the DII to > be > >thrown as the real exception type. > > Don't see how we're gonna come up with anything agreeable in this > space. > You either have the compile-time info, or you don't. Avoiding static > ctors > is a must. I agree. Now, consider: if the DII does not always return UnknownUserException, that seems to imply that there must be a static constructor somewhere, yes? (Because I can't see a way of instantiating a concrete user exception any other way.) So, isn't UnknownUserException the *only* option that avoids static constructors? > So you would have to come up with some way of having the > application pass some kind of unmarshaling info into the DII, sort > of like > ExceptionLists containing not TypeCodes but instead containing some > kind of > objects that encapsulate the unmarshaling code for each possible > exception. > And there you're getting very much into ORB implementation > territory. This > is of course easily done in Java because of their portable > stubs. Orbix > 2000 for C++ could also easily do this, but I don't know about other > C++ ORBs. It would be doable for us, but I'm not sure that's the way it should be. To me, it should be up to the *application code* (not the ORB) to decide how to deal with the DII and user exceptions. In other words, the ORB should always instantiate UnknownUserException. Then, if I happen to use the DII but also have the stubs linked in for some reason, I can choose to use a helper function to do the conversion to a concrete exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 27 Jan 2000 08:53:49 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: C++ Revision Task Force Subject: RE: UnknownUserException and stubs In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140317@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: lMJe9/0Pd95GF!!'7Ce9 On Wed, 26 Jan 2000, Paul Kyzivat wrote: > My logic was that the name suggests the original *intent*. > If that was the case, then we are also making a change that violates > that > original intent. > > Of course we are free to do that if, after consideration, we decide > that is > the right thing to do. But it is a bigger change than fixing an > oversight. > > I can see pros and cons either way. However I think permitting a > "known" > exception to be reported either way has the disadvantages of both > and the > advantages of neither. We could add a typedef that creates a more intuitive name, but leaves UnknownUserException valid. (Maybe we should have called it DIIUserException from the beginning...) Cheers, Michi. Date: Tue, 29 May 2001 15:26:24 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force Subject: Proposal for 3246 Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _,Q!!&S*e9NH6e9 Change section 1.19.2 to read as follows: Request invocations made through the DII may raise user exceptions. User exceptions are always returned to the caller as the exception DIIUserException: // C++ class DIIUserException : public UserException { public: Any & exception(); // Deprecated Any * get_exception_as_any() const; DynamicAny::DynStruct * get_exception_as_dyn_any() const; }; typedef DIIUserException UnknownUserException; // Deprecated old name [ Editorial remark: Note that I deprecated exception() for two reasons: - The name isn't very nice at all. After all, the operation returns an Any, not an exception. - I think the method should have been const all along. - The normal memory management rules are violated by returning a reference instead of a dynamically-allocated copy. The replacements, get_exception_as_any() and get_exception_as_dyn_any(), are const-correct and allow me to pull the exception out as a DynStruct directly, instead of first having to get the Any, then constructing a DynAny from the Any, and then down-casting the DynAny to a DynStruct. (And they do away with the special mapping rule too.) ] Note that the name UnknownUserException is a synonym for DIIUserException. UnknownUserException is deprecated but currently retained for backward compatibility with previous mapping implementations; it will be removed in a future version of the C++ mapping. DIIUserException is derived from UserException. It provides the get_exception_as_any() accessor that returns an Any holding the actual exception. Ownership of the returned Any is maintained by the DIIUserException--the Any merely allows access to the exception data. For example, if the calling program has the stubs for the user exceptions ApplicationError1 and ApplicationError2 linked in (and therefore has access to the generated type-specific Any extraction operators), an invocation might look as follows: // ... req->invoke(); if (CORBA::DIIUserException * diiuep = req->env()->dii_user_exception()) { CORBA::Any_var av = diiuep->get_exception_as_any(); const ApplicationError1 * ae1; const ApplicationError2 * ae2; if (*av >>= ae1) { // Deal with ApplicationError1... } else if (*a >>= ae2) { // Deal with ApplicationError2... } // ... } [ Editorial note: I've added dii_user_exception() method to the Environment class. That's because, otherwise, I have to first pull out an exception pointer and then downcast it to a DIIUserException pointer before I can extract the exception. ] If the calling program does not have the stubs linked in, it can use DynAny to parse the exception returned by Env::dii_user_exception(): // ... req->invoke(); if (CORBA::DIIUserException * diiuep = req->env()->dii_user_exception()) { DynamicAny::DynStruct_var dsv = diiuep->get_exception_as_dyn_any(); // Use dsv to parse the contents of the exception... } // ... Conforming applications should never explicitly throw exceptions of type DIIUserException--it is intended for use with the DII only. Opinions? Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Wed, 30 May 2001 10:10:34 +1000 (EST) From: Michi Henning To: C++ Revision Task Force Subject: Re: Proposal for 3246 In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PFQ!!GM9!!6fLe9#i'!! Status: RO On Tue, 29 May 2001, Michi Henning wrote: > class DIIUserException : public UserException { > public: > Any & exception(); // Deprecated > Any * get_exception_as_any() const; > DynamicAny::DynStruct * get_exception_as_dyn_any() > const; > }; Hmmm... Looks like I screwed up. While this is very nice, it creates a circular dependency between the CORBA and the DynamicAny modules, which is definitely a no-no. So, it looks like the get_exception_as_dyn_any() operation will have to go, no matter how nice it would be to have it... Here is the modified proposal: Change section 1.19.2 to read as follows: Request invocations made through the DII may raise user exceptions. User exceptions are always returned to the caller as the exception DIIUserException: // C++ class DIIUserException : public UserException { public: Any & exception(); // Deprecated Any * get_exception_as_any() const; }; typedef DIIUserException UnknownUserException; // Deprecated old name [ Editorial remark: Note that I deprecated exception() for three reasons: - The name isn't very nice at all. After all, the operation returns an Any, not an exception. - I think the method should have been const all along. - The normal memory management rules are violated by returning a reference instead of a dynamically-allocated copy. ] Note that the name UnknownUserException is a synonym for DIIUserException. UnknownUserException is deprecated but currently retained for backward compatibility with previous mapping implementations; it will be removed in a future version of the C++ mapping. DIIUserException is derived from UserException. It provides the get_exception_as_any() accessor that returns an Any holding the actual exception. (The returned Any must be deallocated according to the normal memory management rules.) For example, if the calling program has the stubs for the user exceptions ApplicationError1 and ApplicationError2 linked in (and therefore has access to the generated type-specific Any extraction operators), an invocation might look as follows: // ... req->invoke(); if (CORBA::DIIUserException * diiuep = req->env()->dii_user_exception()) { CORBA::Any_var av = diiuep->get_exception_as_any(); const ApplicationError1 * ae1; const ApplicationError2 * ae2; if (*av >>= ae1) { // Deal with ApplicationError1... } else if (*av >>= ae2) { // Deal with ApplicationError2... } // ... } // ... [ Editorial note: I've added dii_user_exception() method to the Environment class. That's because, otherwise, I have to first pull out an exception pointer and then downcast it to a DIIUserException pointer before I can extract the exception. ] If the calling program does not have the stubs linked in, it can use DynAny to parse the exception returned by Env::dii_user_exception(): // ... DynamicAny::DynAnyFactory_var daf = ...; req->invoke(); if (CORBA::DIIUserException * diiuep = req->env()->dii_user_exception()) { CORBA::Any_var av = diiuep->get_exception_as_any(); DynamicAny::DynAny_var dav = daf->create_dyn_any(av); // Use dav to parse the contents of the exception... } // ... Conforming applications should never explicitly throw exceptions of type DIIUserException--it is intended for use with the DII only. Opinions? Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Wed, 30 May 2001 11:20:51 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force Subject: Re: Proposal for 3246 (fwd) Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: +Jcd9(T]d9;oh!!Td6!! Status: RO Jon Biggar just suggested something interesting: > Could get_exception_as_dyn_any() return CORBA::Object instead to break > the cycle? You'd still have to narrow the reference, but it would avoid > the extra potential data copy. I like that a lot. Other opinions? Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi