Issue 2659: On page 59 (Section 6.4.1), ExceptionHolder (messaging-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: On page 59 (Section 6.4.1), ExceptionHolder is defined as follows: //IDL module Messaging { // ... all the other stuff value ExceptionHolder { boolean is_system_exception; boolean byte_order; sequence<octet> marshaled_exception; }; }; This definition requires that the generated <typed>ExceptionHolder unmarshal the marshaled_exception twice: once to get the repositoryId for the exception, and once to actually read the exception. While this can be done (easily in our case since our implementation of InputStream has "get/setPosition()" methods), it seems that including a field with the repository id would make portability easier. On a larger scope, this entire mechanism will add the need to _generate_ code that can unmarshal both system and user exceptions OR it will require a language-mapping specific extension to Messaging::ExceptionHolder that allows it handle the SystemException case. In either case, I think we should clarify this in the spec. As it stands, ExceptionHolder has no specified behaviour, only state. If we expect portable generated code, we need to specify just what compilers can expect of the ExceptionHolder. As far as the Messaging Spec itself, I would suggest the following text be added after the first paragraph of section 6.4.1: "Each language mapping will provide a mechanism for type specific subclasses of ExceptionHolder to obtain any raised SystemExceptions without requiring the subclass to unmarshal the marshaled_exception field. Additional support for raising UserExceptions may also be provided." In the case of Java, I would suggest the following method be added to the implementation of Messaging::ExceptionHolder: public void raise_exception() throws org.omg.CORBA.SystemException, org.omg.CORBA.portable.ApplicationException; Resolution: Add text to specify what the behaviour should be. Revised Text: In section 6.4.2, the following words For each interface, a type specific ExceptionHolder value is generated by the IDL compiler. This ExceptionHolder is implemented by the messaging-aware ORB and passed to an application using the callback model when exception replies are returned from the target. The name of the generated value type is AMI_<ifaceName>ExceptionHolder, where ifaceName is the name of the original interface. This value type is derived from the generic Messaging::ExceptionHolder. should be replaced with : For each interface, a type specific ExceptionHolder value is generated by the IDL compiler. This ExceptionHolder is implemented by the messaging-aware ORB and passed to an application using the callback model when exception replies are returned from the target. The name of the generated value type is AMI_<ifaceName>ExceptionHolder, where ifaceName is the name of the original interface. If the interface <ifaceName> derives from some other IDL interface <baseName>, then the ExceptionHolder for <ifaceName> is derived from AMI_<baseName>ExceptionHolder, but if it does not, then it is derived from Messaging::ExceptionHolder. Actions taken: May 18, 1999: received issue January 9, 2001: closed issue Discussion: I dont believe the problem here is a significant one, and doesnt justify duplicating the repository id information. In the simplest case, the GIOP reply message has just returned from the server to the local client address space where the callback also is, and so to get the repository id of the system exception out of the GIOP message would require parsing of it twice anyway. Close this issue. End of Annotations:===== [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Clarification of Messaging::ExceptionHolder's behavior To: messaging-rtf@omg.org, "Bill @ work" , Ted Horoschak , "bens@trcinc.com" Subject: Clarification of Messaging::ExceptionHolder's behavior From: Charles William Binko Date: Wed, 17 Mar 1999 03:17:44 -0500 Organization: Technical Resource Connection Hello all, First, now that Jon Goldberg's left Inprise, who's running this RTF? There doesn't seem to be much motion here lately. Second, I am finding the following difficulty in implementing the callback method: On page 59 (Section 6.4.1), ExceptionHolder is defined as follows: //IDL module Messaging { // ... all the other stuff value ExceptionHolder { boolean is_system_exception; boolean byte_order; sequence marshaled_exception; }; }; This definition requires that the generated ExceptionHolder unmarshal the marshaled_exception twice: once to get the repositoryId for the exception, and once to actually read the exception. While this can be done (easily in our case since our implementation of InputStream has "get/setPosition()" methods), it seems that including a field with the repository id would make portability easier. On a larger scope, this entire mechanism will add the need to _generate_ code that can unmarshal both system and user exceptions OR it will require a language-mapping specific extension to Messaging::ExceptionHolder that allows it handle the SystemException case. In either case, I think we should clarify this in the spec. As it stands, ExceptionHolder has no specified behaviour, only state. If we expect portable generated code, we need to specify just what compilers can expect of the ExceptionHolder. As far as the Messaging Spec itself, I would suggest the following text be added after the first paragraph of section 6.4.1: "Each language mapping will provide a mechanism for type specific subclasses of ExceptionHolder to obtain any raised SystemExceptions without requiring the subclass to unmarshal the marshaled_exception field. Additional support for raising UserExceptions may also be provided." In the case of Java, I would suggest the following method be added to the implementation of Messaging::ExceptionHolder: public void raise_exception() throws org.omg.CORBA.SystemException, org.omg.CORBA.portable.ApplicationException; Binko Prev by Date: Inheritance of ExceptionHolders Next by Date: unsubscribe Prev by thread: Inheritance of ExceptionHolders Next by thread: issue 2581 -- Messaging RTF Issue Index(es): Date Thread From: Bill Binko To: Messaging-Rtf Subject: Discussion Issue 2659: On page 59 (Section 6.4.1), ExceptionHolde r Date: Wed, 22 Mar 2000 12:29:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: R,\d9'l1e9QIh!!Dp/e9 This issue was mine, and only half of it is addressed in this resolution. The first part (and the part that is dealt with) is that ExceptionHolders will have to unmarshall the exception twice. If that is needed, I can deal with it. The second part of the issue is that it would be very helpful to add the ability for the base ExceptionHolder to throw the exception. This would make portable stubs/skeletons in Java (a thorny issue, but important) much easier. (For the remainder of this discussion, I'll work in Java and leave open how to word the IDL and text to get this result). What I'd like be able to do is generate an ExceptionHolder like the following: IDL: module Simple { exception Ex1{}; interface test { void method1() raises (Ex1); }; }; GENERATES: package Simple; public class AMI_testExceptionHolder extends org.omg.Messaging.ExceptionHolder { /*Constructors, etc*/ public void raise_method1() throws Simple.Ex1 { try { raise_exception(); //SystemExceptions will be raised here } catch (org.omg.CORBA.portable.ApplicationException _exception) { final java.lang.String _exception_id = _exception.getId(); if( _exception_id.equals(Simple.Ex1Helper.id())) { throw Simple.Ex1Helper.read(_exception.getInputStream()); } throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception:" + _exception _id); } } } This implies that org.omg.Messaging.ExceptionHolder has a method with a signature like: void raise_exception() throws org.omg.portable.ApplicationException; Now... This can be sent to the java-rtf, but I think this would be helpful in many languages (such as C++). It makes the generated code simpler and makes portable stubs easier. I also think that this can be defined in the valuetype (but I'm not an expert in that area). What does the RTF think of this part of the issue? Binko From: Bill Binko To: Messaging-Rtf Subject: RE: Discussion Issue 2659: On page 59 (Section 6.4.1), ExceptionH olde r Date: Tue, 28 Mar 2000 13:40:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: KIl!!]b5e9Y+$!!S`7e9 This discussion has also not gotten any discussion. Therefore, could I get the issue number we used to get the sendc and sendp calls added to the Delegate's? I will reword this and send it to the Java-RTF, since it will be _required_ there. I still think this should be done by the Messaging RTF however. Does anyone have any suggestions as to how to proceed with the second half of this? If we vote this down due to the fact that the RepIds will have to be unmarshalled twice anyway, can we still try for a cross-platform mechanism for raising the exception? Binko >-----Original Message----- >From: Bill Binko [mailto:Bill.Binko@trcinc.com] >Sent: Wednesday, March 22, 2000 12:29 PM >To: Messaging-Rtf >Subject: Discussion Issue 2659: On page 59 (Section 6.4.1), >ExceptionHolde r > > >This issue was mine, and only half of it is addressed in this >resolution. >The first part (and the part that is dealt with) is that >ExceptionHolders >will have to unmarshall the exception twice. If that is >needed, I can deal >with it. > >The second part of the issue is that it would be very helpful >to add the >ability for the base ExceptionHolder to throw the exception. >This would >make portable stubs/skeletons in Java (a thorny issue, but >important) much >easier. (For the remainder of this discussion, I'll work in >Java and leave >open how to word the IDL and text to get this result). > >What I'd like be able to do is generate an ExceptionHolder like the >following: >IDL: >module Simple { > exception Ex1{}; > interface test { > void method1() raises (Ex1); > }; >}; > >GENERATES: >package Simple; >public class AMI_testExceptionHolder extends >org.omg.Messaging.ExceptionHolder > { >/*Constructors, etc*/ > > public void raise_method1() > throws Simple.Ex1 > { > try { > raise_exception(); //SystemExceptions will be raised here } catch (org.omg.CORBA.portable.ApplicationException _exception) { final java.lang.String _exception_id = _exception.getId(); if( _exception_id.equals(Simple.Ex1Helper.id())) { throw Simple.Ex1Helper.read(_exception.getInputStream()); } throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception:" + _exception _id); } } } This implies that org.omg.Messaging.ExceptionHolder has a method with a signature like: void raise_exception() throws org.omg.portable.ApplicationException; Now... This can be sent to the java-rtf, but I think this would be helpful in many languages (such as C++). It makes the generated code simpler and makes portable stubs easier. I also think that this can be defined in the valuetype (but I'm not an expert in that area). What does the RTF think of this part of the issue? Binko Sender: Chris.Smith@uab.ericsson.se Message-ID: <38E1B56A.F12F0484@uab.ericsson.se> Date: Wed, 29 Mar 2000 09:48:58 +0200 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Bill Binko CC: Messaging-Rtf Subject: Re: Discussion Issue 2659: On page 59 (Section 6.4.1), ExceptionHolde r References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <_O!!g8De9i#3!!hcod9 Hi Bill, I was trying to respond to this, but couldnt work out the right way to put it... > The second part of the issue is that it would be very helpful to add the > ability for the base ExceptionHolder to throw the exception. This would > make portable stubs/skeletons in Java (a thorny issue, but important) much > easier. (For the remainder of this discussion, I'll work in Java and leave > open how to word the IDL and text to get this result). > > What I'd like be able to do is generate an ExceptionHolder like the > following: > IDL: > module Simple { > exception Ex1{}; > interface test { > void method1() raises (Ex1); > }; > }; > > GENERATES: > package Simple; > public class AMI_testExceptionHolder extends > org.omg.Messaging.ExceptionHolder > { > /*Constructors, etc*/ > > public void raise_method1() > throws Simple.Ex1 > { > try { > raise_exception(); //SystemExceptions will > be raised here > } > catch (org.omg.CORBA.portable.ApplicationException _exception) { > final java.lang.String _exception_id = _exception.getId(); > if( _exception_id.equals(Simple.Ex1Helper.id())) { > throw Simple.Ex1Helper.read(_exception.getInputStream()); > } > throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception:" + > _exception > _id); > } > } > } > > This implies that org.omg.Messaging.ExceptionHolder has a method with a > signature like: > > void raise_exception() throws org.omg.portable.ApplicationException; > > Now... > > This can be sent to the java-rtf, but I think this would be helpful in many > languages (such as C++). It makes the generated code simpler and makes > portable stubs easier. I also think that this can be defined in the > valuetype (but I'm not an expert in that area). > > What does the RTF think of this part of the issue? I think the proposal you have made is probably ok for Java but very difficult if not impossible to do properly in other language mappings. Here is my way of looking at the real problem. If the exception is a user exception, then the generated code should be able to throw it (by parsing the CDR encoded exception and getting the repository id, then using the rest of the CDR encoded exception to "make" the exception). If the exception is a system exception, then we have 2 different situations. In Java, we are in a portable stub environment, and so it is reasonably trivial to map a repository id of a system exception to one of the classes org.omg.CORBA.*. In a C++ etc environment we have no portable stubs, so this is not a problem. The only difficulty I do see is that in Java, each generated ExceptionHolder must have the capability of mapping a system exception rep id to a class. It would be nicer not to repeat this code in every generated exception holder. I think in this case, instead of attempting to make a generic user exception etc. and a raise_exception() operation , we should find some way of providing this hook just in Java. Some suggestions spring to mind a) Language specific mapping of ExceptionHolder, adding a void raiseSystemException(String repId); operation to the mapped ExceptionHolder. b) A new operation on ORB object. c) Some new util object like the ones provided in the Java to IDL mapping. > > Binko From: Bill Binko To: "'Chris Smith'" , Bill Binko Cc: Messaging-Rtf Subject: RE: Discussion Issue 2659: On page 59 (Section 6.4.1), ExceptionH olde r Date: Wed, 29 Mar 2000 11:25:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: I6a!!OONd9@g-e9>=hd9 Chris, Thanks for your comments on both of these issues. I will file new, more targeted, issues for the problems in 1613. As far as this one goes, I will write up a new issue, but would like some input from you (and the group) as to whether this should go to the java-rtf or us. Thanks, Bill PS: My votes will be following shortly. >-----Original Message----- >From: Chris Smith [mailto:uabcsru@uab.ericsson.se] >Sent: Wednesday, March 29, 2000 2:49 AM >To: Bill Binko >Cc: Messaging-Rtf >Subject: Re: Discussion Issue 2659: On page 59 (Section 6.4.1), >ExceptionHolde r > > >Hi Bill, > I was trying to respond to this, but couldnt work out the >right way to put it... > >> The second part of the issue is that it would be very >helpful to add the >> ability for the base ExceptionHolder to throw the exception. > This would >> make portable stubs/skeletons in Java (a thorny issue, but >important) much >> easier. (For the remainder of this discussion, I'll work in >Java and leave >> open how to word the IDL and text to get this result). >> >> What I'd like be able to do is generate an ExceptionHolder like the >> following: >> IDL: >> module Simple { >> exception Ex1{}; >> interface test { >> void method1() raises (Ex1); >> }; >> }; >> >> GENERATES: >> package Simple; >> public class AMI_testExceptionHolder extends >> org.omg.Messaging.ExceptionHolder >> { >> /*Constructors, etc*/ >> >> public void raise_method1() >> throws Simple.Ex1 >> { >> try { >> raise_exception(); //SystemExceptions > will >> be raised here >> } >> catch (org.omg.CORBA.portable.ApplicationException _exception) { >> final java.lang.String _exception_id = _exception.getId(); >> if( _exception_id.equals(Simple.Ex1Helper.id())) { >> throw Simple.Ex1Helper.read(_exception.getInputStream()); >> } >> throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception:" + >> _exception >> _id); >> } >> } >> } >> >> This implies that org.omg.Messaging.ExceptionHolder has a >method with a >> signature like: >> >> void raise_exception() throws org.omg.portable.ApplicationException; >> >> Now... >> >> This can be sent to the java-rtf, but I think this would be >helpful in many >> languages (such as C++). It makes the generated code >simpler and makes >> portable stubs easier. I also think that this can be defined in the >> valuetype (but I'm not an expert in that area). >> >> What does the RTF think of this part of the issue? > >I think the proposal you have made is probably ok for Java but >very difficult if not impossible to do properly in other >language mappings. >Here is my way of looking at the real problem. >If the exception is a user exception, then the generated code >should be able to throw it (by parsing the CDR encoded exception >and getting the repository id, then using the rest of the >CDR encoded exception to "make" the exception). If the exception >is a system exception, then we have 2 different situations. >In Java, we are in a portable stub environment, and so it is >reasonably trivial to map a repository id of a system exception >to one of the classes org.omg.CORBA.*. In a C++ etc environment >we have no portable stubs, so this is not a problem. > >The only difficulty I do see is that in Java, each generated >ExceptionHolder must have the capability of mapping a system >exception rep id to a class. It would be nicer not to repeat >this code in every generated exception holder. > >I think in this case, instead of attempting to make a generic >user exception etc. and a raise_exception() operation >, we should find some way of providing this hook just in Java. > >Some suggestions spring to mind > >a) Language specific mapping of ExceptionHolder, adding a >void raiseSystemException(String repId); operation to the >mapped ExceptionHolder. >b) A new operation on ORB object. >c) Some new util object like the ones provided in the >Java to IDL mapping. > > > > > > > > > > >> >> Binko >