Issue 3077: is_from_poller shoud raise no exception (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: Consider the following illustration: You would like to write some code C++ that does various calls that could raise CORBA exceptions. Among the calls is a type-specific poll. Benefitting from C++ exceptions you would like to handle the possible exceptions at the end. Therefore, if the exception could be from the poller, you would like to find out whether the exception is from an exception reply that was raised by the poller or from an error in receiving the reply. Resolution: resolved Revised Text: In document ptc/00-02-05: Draft Revised CORBA Messaging chapter, p. 1-25, change is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation. The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation, the value FALSE is returned. If the Poller has not yet returned a response to the client, the BAD_INV_ORDER system exception is raised." to read is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation.The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation or the Poller has not yet returned a reply, the valueFALSE is returned. If the Poller has The is_from_poller attribute must not raise any system exception. This is to prevent the requirement for nested exception handling." Actions taken: December 3, 1999: received issue January 9, 2001: closed issue Discussion: The proposed resolution allows to write code in the following style try { // do some calls which could raise CORBA exceptions poller->typeSpecificPoll(timeout, ami_return_val, output_arg); } catch(CORBA::NO_RESPONSE & e) { if (poller->is_from_poller()) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (poller->is_from_poller()) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } Without this resolution, three times nested exception handling is required to get the same effect: CORBA::Boolean isFromPoller = false; try { // do some calls which could raise CORBA exceptions try { poller->typeSpecificPoll(timout, ami_return_val, output_arg); } catch(...) { try // note: three times nested! { isFromPoller = poller->is_from_poller(); } catch(...) {} throw; } } catch(CORBA::NO_RESPONSE & e) { if (isFromPoller) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (isFromPoller) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } I doubt that it was the intent of the original spec to impose this on the applications. Proposed Resolution In document ptc/00-02-05: Draft Revised CORBA Messaging chapter, p. 1-25, change is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation. The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation, the value FALSE is returned. If the Poller has not yet returned a response to the client, the BAD_INV_ORDER system exception is raised." to read is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation.The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation or the Poller has not yet returned a reply, the valueFALSE is returned. If the Poller has The is_from_poller attribute must not raise any system exception. This is to prevent the requirement for nested exception handling." End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Dec 1999 20:48:10 +0100 Message-Id: Subject: is_from_poller shoud raise no exception MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se, messaging-rtf@omg.org, uabcsru@uab.ericsson.se Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Dec 1999 20:48:10 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Dec 1999 20:48:10 +0100" X-UIDL: jg9!!"j(!!#Qgd9R)c!! Hi Chris, your proposed resolution corrects the "is_from_poller" issue and is probably close to the original intention. However, is_from_poller has another serious drawback which could be fixed as part of the same resolution text: it requires nested exception handling. Consider the following illustration: You would like to write some code C++ that does various calls that could raise CORBA exceptions. Among the calls is a type-specific poll. Benefitting from C++ exceptions you would like to handle the possible exceptions at the end. Therefore, if the exception could be from the poller, you would like to find out whether the exception is from an exception reply that was raised by the poller or from an error in receiving the reply. In code, you would like to write something like this: try { // do some calls which could raise CORBA exceptions poller->typeSpecificPoll(timeout, ami_return_val, output_arg); } catch(CORBA::NO_RESPONSE & e) { if (poller->is_from_poller()) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (poller->is_from_poller()) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } As it stands now, the above cannot be achieved. You have to write something like this: CORBA::Boolean isFromPoller = false; try { // do some calls which could raise CORBA exceptions try { poller->typeSpecificPoll(timout, ami_return_val, output_arg); } catch(...) { try // note: three times nested! { isFromPoller = poller->is_from_poller(); } catch(...) {} throw; } } catch(CORBA::NO_RESPONSE & e) { if (isFromPoller) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (isFromPoller) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } I doubt that it was the intent of the original spec to impose this on the applications. -> I propose therefore the following resolution for issue 2878 The words in section 6.6.4 are changed to: "The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. In all other cases, the value FALSE is returned. The is_from_poller attribute may not throw CORBA exceptions. This is to avoid the need for nested exception handling." Anyone thinks I should raise a separate issue for this one? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > Sent: Saturday, November 27, 1999 2:47 PM > To: messaging-rtf; uabcsru > Cc: Chris.Smith > Subject: UNAUTHENTICATED: Messaging Issue 2878 and 2879 > is_from_poller > > > Issue 2878: 6.6.4 is_from_poller (issue 01) (messaging-rtf) > Summary: I would like to raise the following issues with > Messaging. Both > refer to 6.6.4 is_from_poller: 1. The following statement is open > for > interpretation: "The is_from_poller attribute returns the > value TRUE if > and only if the poller operation itself raised a system > exception." Does it refer only to the type-specific poll > operation or to > any operation on the poller that can raise an exception? For > example, a > call to is_ready returns a system exception. What is returned by a > subsequent invocation of is_from_poller? > > I believe the intention here was that the is_from_poller > should only be > concerned with the "type specific operations". Its pretty > obvious if you > call is_ready() and get a system exception that it was the poller > that > raised this, and not the remote object. > > I propose changing the words in section 6.6.4 > > The is_from_poller attribute returns the value TRUE if and only if > the > poller operation itself raised a system exception. If the exception > is > the reply for the asynchonous operation, the value FALSE is > returned. If > the POller has not yet returned a response to the client, the > BAD_INV_ORDER system exception is raised. > > to > > The is_from_poller attribute returns the value TRUE if and only if > the > poller itself has raised a system exception during the > invocation of one > of the type specific poller operations. If the exception > raised from one > of the type specific poller operations is the reply for the > asynchonous > operation, the value FALSE is returned. If the Poller has not yet > returned a response to the client, the BAD_INV_ORDER system > exception is > raised. > > > Issue 2879: 6.6.4 is_from_poller (issue 02) (messaging-rtf) > Summary: 2. If the above quoted statement is correct, the following > statement must be wrong: "If the Poller has not yet returned > a response > to the client, the BAD_INV_ORDER system exception is raised." If the > poller operation itself raises a system exception, the poller has > not > yet returned a response to the client, but should return TRUE > according > to quoted statement under 1. I think that the intended behavior is > be > that the system exception BAD_INV_ORDER is raised, if > is_from_poller is > not called in a context where the previous call (only > type-specific poll > or any? -> see issue 1) to the poller has returned an exception. > > I think this would be a non issue given the above resolution. > I proposed > closing this one. > Sender: Chris.Smith@uab.ericsson.se Message-ID: <385667AF.121603B0@uab.ericsson.se> Date: Tue, 14 Dec 1999 16:52:15 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: messaging-rtf@omg.org, issues@omg.org Subject: Pollers and Exception Holders Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4ll!!8CX!!F+J!!Y:+!! As Dave observed last week, the resolution we adopted for Pollers and ExceptionHolders in the case of multiple interface inheritance does not work..... 3 solutions that I can see.... 1) First inherited interface is mapped to an inherited exception holder or poller, but for further inheritances, the operations of these baseTypes are "rolled" into the generated exception holder or poller 2) Generate an abstract valueType which contains the operations for each interface, and a concrete valueType which inherits from all the abstract valueTypes generated from its inherited interfaces, and from the concrete generic valueType to get the state... I think this doesnt contravene the OBV stuff, but someone should check this. 3) Have no inheritance in the valueTypes and just roll in the operations from the base types..... Thoughts.... Chris From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 14:04:14 +0100 Message-Id: Subject: Resolution proposal to 3077: is_from_poller should not raise exception MIME-Version: 1.0 TO: messaging-rtf@omg.org, uabcsru@uab.ericsson.se Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 14:04:14 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 14:04:14 +0100" X-UIDL: b#+e9)KYd9:cOd9'~Vd9 I propose the following resolution for issue 3077: is_from_is_from_poller requires nested exception handling - Resolution: In document ptc/00-02-05: Draft Revised CORBA Messaging chapter, p. 1-25, change "is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation. The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation, the value FALSE is returned. If the Poller has not yet returned a response to the client, the BAD_INV_ORDER system exception is raised." to read "is_from_poller As described below, the type-specific pollers are queried to obtain the reply from an asynchronously invoked operation. If the reply is a system exception, it may be important for the client application to distinguish between an exception raised by the poll itself and an exception that is actually the reply for the asynchronous invocation. The is_from_poller attribute returns the value TRUE if and only if the poller itself has raised a system exception during the invocation of one of the type specific poller operations. If the exception raised from one of the type specific poller operations is the reply for the asynchronous operation or the Poller has not yet returned a reply, the value FALSE is returned. If the Poller has The is_from_poller attribute must not raise any system exception. This is to prevent the requirement for nested exception handling." - Rational: The above resolution allows to write code in the following style try { // do some calls which could raise CORBA exceptions poller->typeSpecificPoll(timeout, ami_return_val, output_arg); } catch(CORBA::NO_RESPONSE & e) { if (poller->is_from_poller()) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (poller->is_from_poller()) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } Without this resolution, three times nested exception handling is required to get the same effect: CORBA::Boolean isFromPoller = false; try { // do some calls which could raise CORBA exceptions try { poller->typeSpecificPoll(timout, ami_return_val, output_arg); } catch(...) { try // note: three times nested! { isFromPoller = poller->is_from_poller(); } catch(...) {} throw; } } catch(CORBA::NO_RESPONSE & e) { if (isFromPoller) { cout << "no response -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::TIMEOUT & e) { if (isFromPoller) { cout << "timeout is up -> reply has not yet arrived"; } else { cerr << e; throw; } } catch(CORBA::Exception & e) { cerr << e; throw; } I doubt that it was the intent of the original spec to impose this on the applications. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 16 Mar 2000 06:56:57 +0100 Message-Id: Subject: RE: Resolution proposal to 3077: is_from_poller should not raise exception MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 16 Mar 2000 06:56:57 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 16 Mar 2000 06:56:57 +0100" X-UIDL: $2kd9"CMe9(pG!!6%]d9 Hi Chris I just noted that the following straw man to issue 3077 has been forgotten to be included in your vote 1 document. Since the straw man has been posted on the Mailing-List since 3 March and if no one objects, it would be nice if it could still be voted on as part of vote 1. Thanks and regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: Hans z.h.k.k.8. Kneubuehl > Sent: Friday, March 03, 2000 1:30 PM > To: 'messaging-rtf@omg.org'; 'uabcsru' > Subject: Resolution proposal to 3077: is_from_poller should not > raise > exception > > > I propose the following resolution for issue 3077: > is_from_is_from_poller requires nested exception handling > > > - Resolution: > In document ptc/00-02-05: Draft Revised CORBA Messaging > chapter, p. 1-25, change > > "is_from_poller > As described below, the type-specific pollers are queried to > obtain the reply from an > asynchronously invoked operation. If the reply is a system > exception, it may be > important for the client application to distinguish between > an exception raised by the > poll itself and an exception that is actually the reply for > the asynchronous invocation. > The is_from_poller attribute returns the value TRUE if and > only if the poller itself > has raised a system exception during the invocation of one of > the type specific poller > operations. If the exception raised from one of the type > specific poller operations is the > reply for the asynchronous operation, the value FALSE is > returned. If the Poller has > not yet returned a response to the client, the BAD_INV_ORDER > system exception is > raised." > > to read > > "is_from_poller > As described below, the type-specific pollers are queried to > obtain the reply from an > asynchronously invoked operation. If the reply is a system > exception, it may be > important for the client application to distinguish between > an exception raised by the > poll itself and an exception that is actually the reply for > the asynchronous invocation. > The is_from_poller attribute returns the value TRUE if and > only if the poller itself > has raised a system exception during the invocation of one of > the type specific poller > operations. If the exception raised from one of the type > specific poller operations is the > reply for the asynchronous operation or the Poller has not > yet returned a reply, the value > FALSE is returned. If the Poller has The is_from_poller > attribute must not raise any > system exception. This is to prevent the requirement for > nested exception handling." > > > - Rational: > The above resolution allows to write code in the following style > > try > { > // do some calls which could raise CORBA exceptions > > poller->typeSpecificPoll(timeout, ami_return_val, output_arg); > } > catch(CORBA::NO_RESPONSE & e) > { > if (poller->is_from_poller()) > { > cout << "no response -> reply has not yet arrived"; > } > else > { > cerr << e; > throw; > } > } > catch(CORBA::TIMEOUT & e) > { > if (poller->is_from_poller()) > { > cout << "timeout is up -> reply has not yet arrived"; > } > else > { > cerr << e; > throw; > } > } > catch(CORBA::Exception & e) > { > cerr << e; > throw; > } > > > Without this resolution, three times nested exception > handling is required to get the same effect: > > CORBA::Boolean isFromPoller = false; > try > { > // do some calls which could raise CORBA exceptions > > try > { > poller->typeSpecificPoll(timout, ami_return_val, output_arg); > } > catch(...) > { > try // note: three times nested! > { > isFromPoller = poller->is_from_poller(); > } > catch(...) > {} > throw; > } > } > catch(CORBA::NO_RESPONSE & e) > { > if (isFromPoller) > { > cout << "no response -> reply has not yet arrived"; > } > else > { > cerr << e; > throw; > } > } > catch(CORBA::TIMEOUT & e) > { > if (isFromPoller) > { > cout << "timeout is up -> reply has not yet arrived"; > } > else > { > cerr << e; > throw; > } > } > catch(CORBA::Exception & e) > { > cerr << e; > throw; > } > > I doubt that it was the intent of the original spec to impose > this on the applications. > > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 >