Issue 5783: Stub handling of UnknownException (java-rtf) Source: International Business Machines (Ms. Anne E. Collins, nobody) Nature: Uncategorized Issue Severity: Summary: Problem summary: Following resolution of issue 5465 in vote 4, Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet reads as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub does one of the following: - Translates it to org.omg.CORBA.UNKNOWN - Translates it to the nested exception taht the UnknownException contains. - Passes it on directly to the user In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol must always translate the UnknownException to the nested exception given by UnknownException.originalEx. I think there are problems with the new final paragraph a. It's unclear whether the additional paragraph requires a change to Stub code or to the ORB runtime. b. It's undesirable, and unnecessary in this case, to differentiate between ORBs which do and do not implement RMI. The rule can, and should, be the same for all Java ORBs. c. It is incorrect to mandate that any ORB must translate the UnknownException to the nested exception because, as the nested exception is defined as a Throwable, this isn't always possible. Proposal: I think it would be preferable to simply reword Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet, as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user. Resolution: Incorporate change and close issue Revised Text: Replace Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet with the following: If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user Actions taken: December 3, 2002: received issue April 28, 2003: closed issue Discussion: End of Annotations:===== Subject: Stub handling of UnknownException To: issues@omg.org Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 3 Dec 2002 22:10:44 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 03/12/2002 22:11:21 Juergen, Could you please raise the following Java RTF issue. Thanks, Ann ========================================================================== Problem summary: Following resolution of issue 5465 in vote 4, Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet reads as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub does one of the following: - Translates it to org.omg.CORBA.UNKNOWN - Translates it to the nested exception taht the UnknownException contains. - Passes it on directly to the user In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol must always translate the UnknownException to the nested exception given by UnknownException.originalEx. I think there are problems with the new final paragraph a. It's unclear whether the additional paragraph requires a change to Stub code or to the ORB runtime. b. It's undesirable, and unnecessary in this case, to differentiate between ORBs which do and do not implement RMI. The rule can, and should, be the same for all Java ORBs. c. It is incorrect to mandate that any ORB must translate the UnknownException to the nested exception because, as the nested exception is defined as a Throwable, this isn't always possible. Proposal: I think it would be preferable to simply reword Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet, as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user. Ann Date: Tue, 3 Dec 2002 14:20:45 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Stub handling of UnknownException To: issues@omg.org, ann_dalton@uk.ibm.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc I think Ann's version is better than the one I wrote that we just passed. If there are no objections, I'll include Ann's proposal in the next vote. Ken. >Subject: Stub handling of UnknownException >To: issues@omg.org >Cc: java-rtf@omg.org >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a >|January 7, 2002) at 03/12/2002 22:11:21 >MIME-Version: 1.0 > >Juergen, >Could you please raise the following Java RTF issue. >Thanks, >Ann >========================================================================== > >Problem summary: >Following resolution of issue 5465 in vote 4, Section 1.21.6.3 >"Streaming Stub APIs" 3rd main bullet reads as follows: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub does one of the following: > - Translates it to org.omg.CORBA.UNKNOWN > - Translates it to the nested exception taht the UnknownException >contains. > - Passes it on directly to the user > > In order to preserve RMI semantics ORBs implementing the RMI-IIOP >protocol > must always translate the UnknownException to the nested exception >given > by UnknownException.originalEx. > >I think there are problems with the new final paragraph >a. It's unclear whether the additional paragraph requires a change to > Stub code or to the ORB runtime. >b. It's undesirable, and unnecessary in this case, to differentiate > between ORBs which do and do not implement RMI. The rule can, and > should, be the same for all Java ORBs. >c. It is incorrect to mandate that any ORB must translate the > UnknownException to the nested exception because, as the nested > exception is defined as a Throwable, this isn't always possible. > > >Proposal: >I think it would be preferable to simply reword Section 1.21.6.3 > "Streaming Stub APIs" 3rd main bullet, as follows: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested exception that the > UnknownException contains, if possible. If this is not possible, >the > stub passes the UnknownException on directly to the user. > >Ann > Issue 5783: Stub handling of UnknownException ------------------------------------------------------------------------------------------- Problem summary: Following resolution of issue 5465 in vote 4, Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet reads as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub does one of the following: - Translates it to org.omg.CORBA.UNKNOWN. - Translates it to the nested exception that the UnknownException contains. - Passes it on directly to the user. In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol must always translate the UnknownException to the nested exception given by UnknownException.originalEx. I think there are problems with the new final paragraph: a. It's unclear whether the additional paragraph requires a change to Stub code or to the ORB runtime. b. It's undesirable, and unnecessary in this case, to differentiate between ORBs which do and do not implement RMI. The rule can, and should, be the same for all Java ORBs. c. It is incorrect to mandate that any ORB must translate the UnknownException to the nested exception because, as the nested exception is defined as a Throwable, this isn't always possible. Proposed Resolution: (from Ann Dalton) I think it would be preferable to simply reword Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet, as follows: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Dec 2002 14:19:04 -0800 To: Ken Cavanaugh , java-rtf@omg.org From: Andy Piper Subject: Re: Vote 5 (due 5 pm PST 12/17/02) BEA votes as follows: 2889: YES 3633: YES 3995: YES 4010: YES 5696: NO - I do not believe it is acceptable to rely on optional vendor-specifc features to compile legal IDL into legal Java. 5728: YES 5782: YES 5783: NO - whilst I agree that it should be the Stub that performs these operations, the nested exceptions is marshaled as a java Throwable and therefore _must_ be possible to be extracted if the underlying ORB understands RMI (and valuetypes). I would be happier with: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested Throwable that the UnknownException contains. andy Date: Tue, 10 Dec 2002 14:40:21 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 (due 5 pm PST 12/17/02) To: Ken.Cavanaugh@sun.com, java-rtf@omg.org, andyp@bea.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: Ken Cavanaugh , java-rtf@omg.org >From: Andy Piper >Subject: Re: Vote 5 (due 5 pm PST 12/17/02) >Mime-Version: 1.0 > >BEA votes as follows: > >2889: YES >3633: YES >3995: YES >4010: YES >5696: NO - I do not believe it is acceptable to rely on optional >vendor-specifc features to compile legal IDL into legal Java. But that is not what is happening here. The legal IDL compiles into legal java WITHOUT any -pkgprefix change. #pragma prefix simply has no effect on the generated Java packages, so there is no problem in the generated code. If you are looking for a standard mechanism to set the Java package in the generated code, we have never had one, and I'm not sure anyone really wants to standardize this area. >5728: YES >5782: YES >5783: NO - whilst I agree that it should be the Stub that performs >these >operations, the nested exceptions is marshaled as a java Throwable >and >therefore _must_ be possible to be extracted if the underlying ORB >understands RMI (and valuetypes). I would be happier with: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested Throwable that the > UnknownException contains. > If you and Ann agree on a revised wording, I'll be happy to include the changes in this vote. Thanks, Ken. Subject: Re: Vote 5 - issue 5783 To: Andy Piper Cc: java-rtf@omg.org, Ken Cavanaugh X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Wed, 11 Dec 2002 15:31:33 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 11/12/2002 15:32:08 > 5783: NO - whilst I agree that it should be the Stub that performs these > operations, the nested exceptions is marshaled as a java Throwable and > therefore _must_ be possible to be extracted if the underlying ORB > understands RMI (and valuetypes). I would be happier with: > - If the CORBA system exception org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested Throwable that the > UnknownException contains. Andy, The issue is not that the ORB can't extract the nested exception but that the Stub can't throw it back to the application. The Stub method is not defined to throw Throwable, nor the application to catch it. The Stub can, and I believe should, throw back the nested exception when it is an Error or a RuntimeException, which are the most likely. But if for some reason the nested exception is some checked exception, then the best the Stub can do is throw back the UnknownException. So I think the final sentence is still required. Would you be happier with - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, for example if the nested exception is a checked exception, the stub passes the UnknownException on directly to the user. I didn't really want to be specific as to why the Stub might be unable to throw the nested exception back because it should never be a checked exception, and to suggest it might could be confusing. However, this is error processing so it could be, most likely due to mismatched application classes I would guess. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Dec 2002 11:08:44 -0800 To: "Ann Dalton1" From: Andy Piper Subject: Re: Vote 5 - issue 5783 Cc: java-rtf@omg.org, Ken Cavanaugh At 03:31 PM 12/11/2002 +0000, Ann Dalton1 wrote: The issue is not that the ORB can't extract the nested exception but that the Stub can't throw it back to the application. The Stub method is not defined to throw Throwable, nor the application to catch it. The Stub can, and I believe should, throw back the nested exception when it is an Error or a RuntimeException, which are the most likely. But if for some reason the nested exception is some checked exception, then the best the Stub can do is throw back the UnknownException. I don't believe this can ever be the case since the checked exception would have to be reflected in the remote interface on the server-side. If there is some application mismatch then I would suggest that something more serious should be thrown. So I think the final sentence is still required. Would you be happier with - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, for example if the nested exception is a checked exception, the stub passes the UnknownException on directly to the user. Its the "if possible" that I'm not happy about. Ideally the RMI spec would tell us what to do in this instance, but I'm not sure it says anything. Maybe change "is possible" to "if the exception is unchecked, or checked and declared by the stub"? andy Date: Thu, 12 Dec 2002 00:17:35 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Andy Piper CC: Ann Dalton1 , java-rtf@omg.org, Ken Cavanaugh Subject: Re: Vote 5 - issue 5783 Andy, This section of the IDL to Java spec describes the behavior of IDL stubs. So the RMI spec cannot tell us what to do in this instance. In general the checked exception thrown by these stubs would match the checked exceptions declared by an RMI-IIOP server, but this is not always the case. If the RMI-IIOP server declares a checked RemoteException or any of its subclasses, this will not be mapped to any checked exception in IDL but it will be mapped to an UnknownException on the wire. In this case, it may not even be possible for the client ORB to unmarshal the nested exception (if it is for a subclass of RemoteException that is not available to the client application). If the client ORB can unmarshal the nested RemoteException or subclass, the IDL stub won't be able to throw it because it is an undeclared checked exception. Another possibility is that the server is IDL rather than RMI, and has thrown an UnknownException with a nested checked exception. This is perfectly legal behavior. Having said all this, I am OK with your proposed change of "if possible" to "if the exception is unchecked, or checked and declared by the stub". Simon Andy Piper wrote: > > At 03:31 PM 12/11/2002 +0000, Ann Dalton1 wrote: > >The issue is not that the ORB can't extract the nested exception but that > >the Stub can't throw it back to the application. The Stub method is not > >defined to throw Throwable, nor the application to catch it. > >The Stub can, and I believe should, throw back the nested exception > >when it is an Error or a RuntimeException, which are the most likely. > >But if for some reason the nested exception is some checked exception, > >then the best the Stub can do is throw back the UnknownException. > > I don't believe this can ever be the case since the checked exception would > have to be reflected in the remote interface on the server-side. If there > is some application mismatch then I would suggest that something more > serious should be thrown. > > >So I think the final sentence is still required. Would you be happier > >with > >- If the CORBA system exception org.omg.CORBA.portable.UnknownException > > is thrown, the stub translates it to the nested exception that the > > UnknownException contains, if possible. If this is not possible, for > > example if the nested exception is a checked exception, the stub > > passes the UnknownException on directly to the user. > > Its the "if possible" that I'm not happy about. Ideally the RMI spec would > tell us what to do in this instance, but I'm not sure it says anything. > Maybe change "is possible" to "if the exception is unchecked, or checked > and declared by the stub"? > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Dec 2002 16:55:16 -0800 To: Simon Nash From: Andy Piper Subject: Re: Vote 5 - issue 5783 Cc: Ann Dalton1 , java-rtf@omg.org, Ken Cavanaugh At 12:17 AM 12/12/2002 +0000, Simon Nash wrote: Another possibility is that the server is IDL rather than RMI, and has thrown an UnknownException with a nested checked exception. This is perfectly legal behavior. Ok. Having said all this, I am OK with your proposed change of "if possible" to "if the exception is unchecked, or checked and declared by the stub". Cool. andy Date: Wed, 11 Dec 2002 17:40:24 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 - issue 5783 To: ann_dalton@uk.ibm.com, andyp@bea.com Cc: java-rtf@omg.org, Ken.Cavanaugh@Sun.COM X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Does the following capture the agreed changes for 5783? Proposed Resolution: Replace the third main bullet of section 1.21.6.3 with: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if the nested exception is unchecked, or checked and declared by the stub. If this is not possible, for example if the nested exception is a checked exception, the stub passes the UnknownException on directly to the user. Thanks, Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Dec 2002 18:58:35 -0800 To: Ken Cavanaugh , ann_dalton@uk.ibm.com From: Andy Piper Subject: Re: Vote 5 - issue 5783 Cc: java-rtf@omg.org, Ken.Cavanaugh@sun.com At 05:40 PM 12/11/2002 -0800, Ken Cavanaugh wrote: Does the following capture the agreed changes for 5783? Re-reading I would say: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains if the nested exception is unchecked, or checked and declared by the stub. If this is not possible, for example if the nested exception is a checked exception undeclared by the stub, the stub passes the UnknownException on directly to the user. Date: Wed, 11 Dec 2002 23:12:15 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 - issue 5783 To: Ken.Cavanaugh@Sun.COM, ann_dalton@uk.ibm.com, andyp@bea.com Cc: java-rtf@omg.org, Ken.Cavanaugh@Sun.COM X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: Ken Cavanaugh , ann_dalton@uk.ibm.com >From: Andy Piper >Subject: Re: Vote 5 - issue 5783 >Cc: java-rtf@omg.org, Ken.Cavanaugh@Sun.COM >Mime-Version: 1.0 > >At 05:40 PM 12/11/2002 -0800, Ken Cavanaugh wrote: >>Does the following capture the agreed changes for 5783? > >Re-reading I would say: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested exception that the > UnknownException contains if the nested exception is unchecked, or > checked and declared by the stub. If this is not possible, for > example if the nested exception is a checked exception undeclared >by the > stub, the stub passes the UnknownException on directly to the >user. > This version looks fine to me. If it is acceptable to Ann, I'll accept this as a friendly amendment and ask everyone to reconsider their vote on this issue, or to simply let their current vote stand, if they have already voted and do not wish to change their vote. Thanks, Ken. Subject: Re: Vote 5 - issue 5783 To: Ken Cavanaugh Cc: andyp@bea.com, java-rtf@omg.org, Ken.Cavanaugh@sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Thu, 12 Dec 2002 11:06:58 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 12/12/2002 11:07:40 Fine by me Ann Ken Cavanaugh andyp@bea.com cc: java-rtf@omg.org, Ken.Cavanaugh@Sun.COM 12/12/2002 07:12 Subject: Re: Vote 5 - issue 5783 Please respond to Ken Cavanaugh >X-Sender: andyp@san-francisco.beasys.com >To: Ken Cavanaugh , ann_dalton@uk.ibm.com >From: Andy Piper >Subject: Re: Vote 5 - issue 5783 >Cc: java-rtf@omg.org, Ken.Cavanaugh@Sun.COM >Mime-Version: 1.0 > >At 05:40 PM 12/11/2002 -0800, Ken Cavanaugh wrote: >>Does the following capture the agreed changes for 5783? > >Re-reading I would say: > >- If the CORBA system exception >org.omg.CORBA.portable.UnknownException > is thrown, the stub translates it to the nested exception that the > UnknownException contains if the nested exception is unchecked, or > checked and declared by the stub. If this is not possible, for > example if the nested exception is a checked exception undeclared >by the > stub, the stub passes the UnknownException on directly to the >user. > This version looks fine to me. If it is acceptable to Ann, I'll accept this as a friendly amendment and ask everyone to reconsider their vote on this issue, or to simply let their current vote stand, if they have already voted and do not wish to change their vote. Thanks, Ken. Date: Thu, 12 Dec 2002 10:45:19 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Vote 5 - issue 5783 To: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc After all of the discussions about the wording of 5783, everyone has agreed to the following modification of the proposed resolution: Proposed Resolution: Replace the third main bullet of section 1.21.6.3 with: - If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains if the nested exception is unchecked, or checked and declared by the stub. If this is not possible, for example if the nested exception is a checked exception undeclared by the stub, the stub passes the UnknownException on directly to the user. This is the version that I would now like to include in vote 5. For those who have not yet voted, please consider this version of the proposal. For those who have already voted, please consider whether the updated proposal requires any change in your vote. As Jishnu says, vote early and often, but only your last vote counts. Vote 5 is still due 5 pm PST on December 17, 2002. Thanks, Ken.