Issue 1583: org.omg.CORBA.UserException class not specified (java-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: The current mapping does not specify the org.omg.CORBA.UserException class. I propose the mapping below. All generated user exception constructors should then pass the exception"s id to the UserException string constructor. The toString() method on the exception will then output the Exception"s type id. package org.omg.CORBA; public abstract class UserException extends java.lang.Exception { public UserException() { } public UserException(String r) { super(r); } } Resolution: closed issue Revised Text: Actions taken: June 26, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: ccaffrey@eng-mail Date: Thu, 25 Jun 1998 17:28:17 -0400 To: issues@omg.org, java-rtf@omg.org From: Colm Caffrey Subject: org.omg.CORBA.UserException class The current mapping does not specify the org.omg.CORBA.UserException class. I propose the mapping below. All generated user exception constructors should then pass the exception's id to the UserException string constructor. The toString() method on the exception will then output the Exception's type id. package org.omg.CORBA; public abstract class UserException extends java.lang.Exception { public UserException() { } public UserException(String r) { super(r); } } Return-Path: Date: Fri, 26 Jun 1998 13:52:21 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Colm Caffrey Cc: java-rtf@omg.org Subject: Re: org.omg.CORBA.UserException class References: <3.0.32.19980625172816.00a71910@eng-mail> Colm, A few questions: 1. Why are these constructors public? For org.omg.CORBA,SystemException, there are no public constructors. Is is valid to create an instance of the UserException class itself, rather than a subclass? 2. In your description, is the exception id (type id) the same as what the java.lang.Exception description calls the detail message? If so, I suggest use of the latter term to avoid confusion. 3. How will this affect the example on page 23-25 of the spec? Will the mapping for ex1 change so that there is another constructor with two String parameters, one for the detail message and one for the user-declared field "reason"? Also, what does the ex1 constructor with only one string argument do? Does it pass the string up to the superclass constructor, or store it in ex1's reason field and call the default superclass constructor? I think it should be the former, but this needs to be defined. 4. Does this require a change to the UnknownUserException definition to add a constructor with a String argument? It's not clear to me what the purpose of UnknownUserException is (there's no explanation in the spec of how it's used), so I would appreciate it if someone could give me a pointer that explains why we have this in the spec. Simon Colm Caffrey wrote: > > The current mapping does not specify the org.omg.CORBA.UserException > class. I propose the mapping below. All generated user exception > constructors should then pass the exception's id to the > UserException > string constructor. The toString() method on the exception will then > output the Exception's type id. > > package org.omg.CORBA; > > public abstract class UserException extends java.lang.Exception > { > public UserException() > { > } > > public UserException(String r) > { > super(r); > } > } -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: raz@arrakis.com.au Date: Fri, 26 Jun 1998 10:51:33 -0300 From: Roland Turner Organization: - To: Colm Caffrey CC: issues@omg.org, java-rtf@omg.org Subject: Re: org.omg.CORBA.UserException class References: <3.0.32.19980625172816.00a71910@eng-mail> Colm Caffrey wrote: > The current mapping does not specify the org.omg.CORBA.UserException > class. Well, it provides source code, how much more do you want? >From orbos/98-03-10, page A-60 abstract public class UserException extends java.lang.Exception { } > I propose the mapping below. All generated user exception > constructors should then pass the exception's id to the > UserException > string constructor. The toString() method on the exception will then > output the Exception's type id. Is the exception's name not adequate? - Raz Return-Path: X-Sender: ccaffrey@eng-mail Date: Fri, 26 Jun 1998 11:25:26 -0400 To: nash@hursley.ibm.com From: Colm Caffrey Subject: Re: org.omg.CORBA.UserException class Cc: java-rtf@omg.org At 01:52 PM 6/26/98 +0100, you wrote: >Colm, >A few questions: > >1. Why are these constructors public? For org.omg.CORBA,SystemException, > there are no public constructors. Is is valid to create an instance > of the UserException class itself, rather than a subclass? The constructors need to be public as they are invoked by classes in different packages. > >2. In your description, is the exception id (type id) the same as what the > java.lang.Exception description calls the detail message? If so, I > suggest use of the latter term to avoid confusion. > The string constructor adds the type id to the exception's detail message. >3. How will this affect the example on page 23-25 of the spec? Will > the mapping for ex1 change so that there is another constructor > with two String parameters, one for the detail message and one for > the user-declared field "reason"? Also, what does the ex1 > constructor > with only one string argument do? Does it pass the string up to > the > superclass constructor, or store it in ex1's reason field and call > the > default superclass constructor? I think it should be the former, > but > this needs to be defined. > The signatures of User Exception constructors will not change. But all the UserException constructors will invoke... super(Helper.id()); >4. Does this require a change to the UnknownUserException definition > to add a constructor with a String argument? It's not clear to me > what the purpose of UnknownUserException is (there's no > explanation in > the spec of how it's used), so I would appreciate it if someone > could > give me a pointer that explains why we have this in the spec. > No changes are needed to UnknownUserException. The UnknownUserException class is used to pass user exceptions to the generated stubs so that the stub can extract the exception construct the class. The ORB does not know how to construct user exception objects. This proposal is a fairly minor change that should aid debugging of applications that receive User Exceptions. Cheers, Colm. > Simon > >Colm Caffrey wrote: >> >> The current mapping does not specify the org.omg.CORBA.UserException >> class. I propose the mapping below. All generated user exception >> constructors should then pass the exception's id to the UserException >> string constructor. The toString() method on the exception will then >> output the Exception's type id. >> >> package org.omg.CORBA; >> >> public abstract class UserException extends java.lang.Exception >> { >> public UserException() >> { >> } >> >> public UserException(String r) >> { >> super(r); >> } >> } > >-- >Simon C Nash, IBM Java Technology Centre, Hursley, UK >MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 >Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb > > Return-Path: Date: Fri, 26 Jun 1998 17:05:06 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Colm Caffrey Cc: java-rtf@omg.org Subject: Re: org.omg.CORBA.UserException class References: <3.0.32.19980626112524.00f20d08@eng-mail> Colm, Colm Caffrey wrote: > > At 01:52 PM 6/26/98 +0100, you wrote: > >Colm, > >A few questions: > > > >1. Why are these constructors public? For > org.omg.CORBA,SystemException, > > there are no public constructors. Is is valid to create an > instance > > of the UserException class itself, rather than a subclass? > > The constructors need to be public as they are invoked by classes in > different packages. > They can be protected if they are only invoked by super() calls. I > think this will always be the case. > > > >2. In your description, is the exception id (type id) the same as > what the > > java.lang.Exception description calls the detail message? If > so, I > > suggest use of the latter term to avoid confusion. > > > > The string constructor adds the type id to the exception's detail > message. > OK, I understand. > >3. How will this affect the example on page 23-25 of the spec? Will > > the mapping for ex1 change so that there is another constructor > > with two String parameters, one for the detail message and one for > > the user-declared field "reason"? Also, what does the ex1 constructor > > with only one string argument do? Does it pass the string up to the > > superclass constructor, or store it in ex1's reason field and call the > > default superclass constructor? I think it should be the former, but > > this needs to be defined. > > > > The signatures of User Exception constructors will not change. But all > the UserException constructors will invoke... > > super(Helper.id()); > If this is true, why do we need a no-argument constructor for UserException? Is it just for use by UnknownUserException? > >4. Does this require a change to the UnknownUserException definition > > to add a constructor with a String argument? It's not clear to me > > what the purpose of UnknownUserException is (there's no explanation in > > the spec of how it's used), so I would appreciate it if someone could > > give me a pointer that explains why we have this in the spec. > > > > No changes are needed to UnknownUserException. The UnknownUserException > class is used to pass user exceptions to the generated stubs so that the > stub can extract the exception construct the class. The ORB does not know > how to construct user exception objects. > Thanks for clarifying the purpose of this. I would like to propose that these words of explanation be added to the spec. BTW, if it's just for use by the stubs, I would have expected it to be called org.omg.CORBA.portable.UnknownUserException. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Sun, 28 Jun 1998 20:10:43 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Colm Caffrey Cc: java-rtf@omg.org Subject: Re: org.omg.CORBA.UserException class References: <3.0.32.19980625172816.00a71910@eng-mail> <3593A765.4621A5B4@arrakis.com.au> Colm, Roland Turner wrote: > > Colm Caffrey wrote: > > > I propose the mapping below. All generated user exception > > constructors should then pass the exception's id to the > UserException > > string constructor. The toString() method on the exception will > then > > output the Exception's type id. > > Is the exception's name not adequate? > > - Raz I was a little uneasy about this too. Can you post an example of what the toString() output would look like if the type ID were included? Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: X-Sender: ccaffrey@eng-mail Date: Thu, 09 Jul 1998 16:23:17 -0400 To: java-rtf@omg.org From: Colm Caffrey Subject: org.omg.CORBA.UserException class Folks, The following is the revised UserException change proposal which was discussed at todays RTF conf. call. Change the UserException class to be as follows ... package org.omg.CORBA; public abstract class UserException extends java.lang.Exception { protected UserException() { } protected UserException(String r) { super(r); } } All generated user exception constructors should pass the exception's type id to the UserException string constructor. This means that the toString() operation will output the full class name and the IDL exception's typeid. Having the typeid gives full module and version information. Note that the correct module information can not be detected from the exception class name only as other packaging may have been applied by the IDL compiler. Also an extra constructor is generated for all user-def exceptions which takes each of the exception's members and an extra reason string. The reason string is appended to the exception's type id and is passed to the UserException constructor. EG: // IDL exception reject { string name; short number; }; // Generated Java class public class reject { public reject() { super(rejectHelper.id()); } public reject(String name, short number) { super(rejectHelper.id()); this.name = name; this.number = number; } public reject(String name, short number, String _reason) { super(rejectHelper.id() + " " + reason); this.name = name; this.number = number; } } Cheers, Colm. Return-Path: Date: Thu, 09 Jul 1998 23:00:54 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Colm Caffrey Cc: java-rtf@omg.org Subject: Re: org.omg.CORBA.UserException class References: <3.0.32.19980709162315.00a6de10@eng-mail> Colm, Looks good. A couple of typos: the "reject" Java class should extend org,omg.CORBA.UserException, and the reason string should be _reason in the code as well as the argument list. Simon Colm Caffrey wrote: > > Folks, > > The following is the revised UserException change proposal which was > discussed at todays RTF conf. call. > > Change the UserException class to be as follows ... > > package org.omg.CORBA; > > public abstract class UserException extends java.lang.Exception > { > protected UserException() > { > } > > protected UserException(String r) > { > super(r); > } > } > > All generated user exception constructors should pass the > exception's > type id to the UserException string constructor. This means that the > toString() operation will output the full class name and the IDL > exception's typeid. Having the typeid gives full module and version > information. Note that the correct module information can not be > detected from the exception class name only as other packaging may > have been applied by the IDL compiler. > > Also an extra constructor is generated for all user-def exceptions > which takes each of the exception's members and an extra reason > string. > The reason string is appended to the exception's type id and is > passed > to the UserException constructor. > > EG: > > // IDL > exception reject > { > string name; > short number; > }; > > // Generated Java class > public class reject > { > public reject() > { > super(rejectHelper.id()); > } > > public reject(String name, short number) > { > super(rejectHelper.id()); > this.name = name; > this.number = number; > } > > public reject(String name, short number, String _reason) > { > super(rejectHelper.id() + " " + reason); > this.name = name; > this.number = number; > } > } > > Cheers, > > Colm. -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb