Issue 778: Proposed IFR exceptions (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {}; Resolution: Incorporate changes in 2.3a and close issue. Revised Text: 1. In Chapter 3 section 3.17.2 table of minor codes add the following rows in the BAD_PARAM group: Actions taken: November 7, 1997: received issue February 22, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 07 Nov 1997 13:26:25 +0000 From: Terence Cross Organization: Iona Tech., +353 1 6022111 x 2266, http://www-irl.iona.com/hyplan/tcross/ To: orb_revision@omg.org Subject: ORB Core RTF References: <344CED17.C336FF47@iona.com> Hi, in reponse to the action point from the Dublin meeting I include the following. (1) Proposed IFR exceptions: raised by destroy() and move(): exception DependencyExists {}; rasied by the create_*() and move(): exception RIDAlreadyDefined {}; exception NameAlreadyDefined {}; Can anyone think of any other exceptions for the IFR? Return-Path: Sender: jis@fpk.hp.com Date: Tue, 08 Sep 1998 16:25:37 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: orb_revision@omg.org Subject: What to do about the IFR issues? OK, here is something for you all to chew upon for the next couple of days. I propose that we consolidate all the IFR error reporting issues (85, 423, 424, 432, 441, 442) into the single issue 778 and then at least start working on figuring out a way to resolve 778. To this end I hae put together a strawman resolution of 778 involving all sorts of grodiness that is attached below. I would appreciate comments from y'all about this proposal and any possible cleaner achievable alternatives. If per-chance the attached proposal appears to be acceptable, let me know and I will put together the specific text edits reflecting it. I am holding off on doing that because it will consume considerable effort which I would ratehr not expend if the proposal is a non-starter. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. jis\OMG\ORBRTF\Resolutions\778 Issue 778: Proposed IFR exceptions (orb_revision) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Minor Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {}; The issues 85, 423, 424, 432, 441 and 442 have now been consolidated under this issue. Resolution: The fundamental problem in resolving this issue is that the original design of the IFR interface is based on the fallacious assumption that attributes can return errors. Attributes as such have no way of returning errors (other than via system exceptions - yuck!), as is required by the specification. Given that the IFR interface in its present form is deeply ingrained and widely deployed a fix that involves changing the shape of the interfaces, thus allowing the raising of non-system exceptions would be unacceptable. The only feasible solution for attributes is to raise a system exception with a specific minor code or codes allocated to IFR errors. Since many of the so called errors that are supposed to be returned by the IFR interface operations are triggered by an attempt to set the value of an attribute to something or the other, it seems appropriate to use the BAD_PARAM system exception to signal attempts to set the value to something that is unacceptable. An analysis of the errors that are supposed to be returned by the Write Interfaces of the IFR fall into two categories: 1. Attempt to set the RepositoryID to an already existing one. 2. Attempt to set the name to an already existing one. 3. Attempting to make the required change will destroy an invariant in an irreparable fashion. 4. Conflict of names in an interface with names in any of the base interfaces. Errors need to be returned by the following operations of the following variety: 1. IRObject::destroy attempting to destroy an object that will break invariant. Also attempt to destroy Repository and PrimitiveDefs (type 3). 2. Attribute Contained::id attempting to set it to a value that already exists in the Repository (type 1). 3. Attribute Contained::name attempting to set it to a name that already exists in the context. (type 2). 4. Operation Contained::move attempting to move an object to a target location where either the RepositoryID already exists (type 1) or to a context where the name already exists (type 2). 5. Operation Container::create_* operations when attempt is made to create a contained object with a pre-existing id (type 1) or name (type 2). 6. Attribute InterfaceDef::base_interface when names in the context of any of the base interfaces clash either among themselves or with a name in the context of the derived interface (type 4). 7. Operation InterfaceDef::create_* operations when attempt is made to create an attribute or operation with a pre-existing name in the interface or in any of the interfaces from which it is derived (type 2 or 4), or with a pre-existing Repositoryid (type 1). 8. In interface ValueDef:: Attributes supported_interface, base_value, abstract_base_value if an attempt is made to set them up with names that clash with existing names (type 2 or 4) and existing RepositoryIds (type 1). 9. Operations ValueDef::create_* operations when attempt is made to create a value member, operation or attribute with pre-existing RepositoryIds (type 1) or pre-existing names (type 2) in this ValueDef. Ideally, we would have defined the following exceptions and would have had them raised at appropriate operations: DependencyExists (type 3) RIDAlreadyDefined (type 1) NameAlreadyDefined (type 2 and 4) However, due to historical misfortune this clean solution is too painful to contemplate. The alternative workable, but not the most aesthetically satisfactory solution is described below and is based on the principle that whenever possible IFR specific exceptions are used, but when impossible the BAD_PARAM exception with specific minor value is used. 1. Define the following minor values associated with BAD_PARAM system exception: 2 - RIDAlready Defined in IFR denoted as BAD_PARAM::2 below. 3 - Name Already Defined in IFR Context denoted as BAD_PARAM::3 below. 2. Define the following exceptions: DependencyExists CannotDestroy RIDAlreadyExists NameAlreadyExists 3. Document that the following operations/attributes shall raise the BAD_PARAM exception with the following minor numbers under the following circumstances: i. IRObject::destroy raises DependencyExists on attempt to destroy something that breaks invariance. ii. IRObject::destroy raises CannotDestroy on attempt to destroy the Repository or PrimitiveDefs. iii. Contained::id or the id attribute in any interface derived from Contained raises BAD_PARAM::2 when an attempt is made to set it to a pre-existing RepositoryID value. iv. Contained::name or the name attribute in any interface derived from Contained raises BAD_PARAM::3 when an attempt is made to set the name to a pre-existing name in the context. v. Contained::move and the move operation in all interfaces derived from Contained raises RIDAlreadyExists or the NameAlreadyExists exceptions depending on which of the Repository ID or name clashes at the targetof the move. vi. Container::create_* operations and such operations in all interfaces derived from Container raise the RIDAlreadyExists or the NameAlreadyExists when attempt is made to create things with clashing RepositoryIDs or names respectively. vii. InterfaceDef::base_interface attribute raises BAD_PARAM::3 if name clashes with existing names. viii. ValueDef:: supported_interface, base_value and abstract_base_value attributes raise the BAD_PARAM::2 or BAD_PARAM::3 exceptions on Repository ID clash or name clash respectively. This seems to form a firm and consistent foundation on which these issues can be resolved. Revised Text: Actions to be taken: November 7, 1997: received issue Return-Path: Sender: jon@floorboard.com Date: Tue, 08 Sep 1998 22:47:35 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: What to do about the IFR issues? References: <35F592C1.40AF707@fpk.hp.com> > Jishnu Mukerji wrote: > > OK, here is something for you all to chew upon for the next couple > of > days. I propose that we consolidate all the IFR error reporting > issues > (85, 423, 424, 432, 441, 442) into the single issue 778 and then at > least start working on figuring out a way to resolve 778. To this > end > I > hae put together a strawman resolution of 778 involving all sorts of > grodiness that is attached below. I would appreciate comments from > y'all > about this proposal and any possible cleaner achievable > alternatives. > > If per-chance the attached proposal appears to be acceptable, let me > know and I will put together the specific text edits reflecting > it. I > am > holding off on doing that because it will consume considerable > effort > which I would ratehr not expend if the proposal is a non-starter. In general, I like the proposal. You have done the work that has turned the rest of us off from addressing these problems: categorizing the possible sources and reasons for errors. I have one main problem: You have proposed adding new exceptions to handle the non-attribute cases. What impact does changing the signatures of existing operations have on version compatibility of the specification? Unless the new exceptions are going to carry additional information that helps diagnose the problem (for example, if RIDAlreadyExists returns the IR object that already has the RID), then I think it would be better just to use System Exceptions throughout, which will avoid any version skew difficulties. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jis@fpk.hp.com Date: Wed, 09 Sep 1998 10:38:31 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar Cc: orb_revision@omg.org Subject: Re: What to do about the IFR issues? References: <35F592C1.40AF707@fpk.hp.com> <35F61677.9F2BBBF@floorboard.com> Jonathan Biggar wrote: > In general, I like the proposal. You have done the work that has turned > the rest of us off from addressing these problems: categorizing the > possible sources and reasons for errors. I have one main problem: > > You have proposed adding new exceptions to handle the non-attribute > cases. What impact does changing the signatures of existing operations > have on version compatibility of the specification? Unless the new > exceptions are going to carry additional information that helps diagnose > the problem (for example, if RIDAlreadyExists returns the IR object that > already has the RID), then I think it would be better just to use System > Exceptions throughout, which will avoid any version skew difficulties. I am happy to change the proposed resolution to use only system exceptions. When I was writing it up I could have gone either way. I happened to toss a coin and choose to try out the new exceptions way first. I will write up the system exception only alternative and post it this afternoon. As you point out, it is conceivable that the new exceptions could carry extra information and that would justify their existence. however, I don't think I want to go there in the 2.3 timeframe. maybe we can take another look at this in the 3.0 timeframe, but for now do the minimal fix using system exceptions. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Sender: jis@fpk.hp.com Date: Wed, 09 Sep 1998 11:31:51 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar Cc: orb_revision@omg.org Subject: Issue 778 IFR exceptions alternative proposal References: <35F592C1.40AF707@fpk.hp.com> <35F61677.9F2BBBF@floorboard.com> Jonathan Biggar wrote: > You have proposed adding new exceptions to handle the non-attribute > cases. What impact does changing the signatures of existing > operations > have on version compatibility of the specification? Unless the new > exceptions are going to carry additional information that helps > diagnose > the problem (for example, if RIDAlreadyExists returns the IR object > that > already has the RID), then I think it would be better just to use > System > Exceptions throughout, which will avoid any version skew > difficulties. Attached below is a slightly modified proposal which uses only system exceptions and avoids defining new exceptions. This incidentally also involves much less in the way of editorial change to the chapter.:-) Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. jis\OMG\ORBRTF\Resolutions\778 Issue 778: Proposed IFR exceptions (orb_revision) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Minor Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {}; The issues 85, 423, 424, 432, 441 and 442 have now been consolidated under this issue. Resolution: The fundamental problem in resolving this issue is that the original design of the IFR interface is based on the fallacious assumption that attributes can return errors. Attributes as such have no way of returning errors (other than via system exceptions - yuck!), as is required by the specification. Given that the IFR interface in its present form is deeply ingrained and widely deployed a fix that involves changing the shape of the interfaces, thus allowing the raising of non-system exceptions would be unacceptable. The only feasible solution for attributes is to raise a system exception with a specific minor code or codes allocated to IFR errors. Since many of the so called errors that are supposed to be returned by the IFR interface operations are triggered by an attempt to set the value of an attribute to something or the other, it seems appropriate to use the BAD_PARAM system exception to signal attempts to set the value to something that is unacceptable. An analysis of the errors that are supposed to be returned by the Write Interfaces of the IFR fall into two categories: 1. Attempt to set the RepositoryID to an already existing one. 2. Attempt to set the name to an already existing one. 3. Attempting to make the required change will destroy an invariant in an irreparable fashion. 4. Conflict of names in an interface with names in any of the base interfaces. Errors need to be returned by the following operations of the following variety: 1. IRObject::destroy attempting to destroy an object that will break invariant. Also attempt to destroy Repository and PrimitiveDefs (type 3). 2. Attribute Contained::id attempting to set it to a value that already exists in the Repository (type 1). 3. Attribute Contained::name attempting to set it to a name that already exists in the context. (type 2). 4. Operation Contained::move attempting to move an object to a target location where either the RepositoryID already exists (type 1) or to a context where the name already exists (type 2). 5. Operation Container::create_* operations when attempt is made to create a contained object with a pre-existing id (type 1) or name (type 2). 6. Attribute InterfaceDef::base_interface when names in the context of any of the base interfaces clash either among themselves or with a name in the context of the derived interface (type 4). 7. Operation InterfaceDef::create_* operations when attempt is made to create an attribute or operation with a pre-existing name in the interface or in any of the interfaces from which it is derived (type 2 or 4), or with a pre-existing Repositoryid (type 1). 8. In interface ValueDef:: Attributes supported_interface, base_value, abstract_base_value if an attempt is made to set them up with names that clash with existing names (type 2 or 4) and existing RepositoryIds (type 1). 9. Operations ValueDef::create_* operations when attempt is made to create a value member, operation or attribute with pre-existing RepositoryIds (type 1) or pre-existing names (type 2) in this ValueDef. Ideally, we would have defined the following exceptions and would have had them raised at appropriate operations: DependencyExists (type 3) RIDAlreadyDefined (type 1) NameAlreadyDefined (type 2 and 4) However, due to historical misfortune this clean solution is too painful to contemplate. The alternative workable, but not the most aesthetically satisfactory solution is described below and is based on the principle that whenever possible IFR specific exceptions are used, but when impossible the BAD_PARAM exception with specific minor value is used. 1. Define the following minor values associated with BAD_PARAM system exception: 2 - RIDAlready Defined in IFR denoted as BAD_PARAM::2 below. 3 - Name Already Defined in IFR Context denoted as BAD_PARAM::3 below. 4 - Dependency exists preventing carrying out the operation denoted as BAD_PARAM::4 below. 5 - Attempt to destroy indestructible object denoted as BAD_PARAM::5 below 2. Document that the following operations/attributes shall raise the BAD_PARAM exception with the following minor numbers under the following circumstances: i. IRObject::destroy raises BAD_PARAM::4 on attempt to destroy something that breaks invariance. ii. IRObject::destroy raises BAD_PARAM::5 on attempt to destroy the Repository or PrimitiveDefs. iii. Contained::id or the id attribute in any interface derived from Contained raises BAD_PARAM::2 when an attempt is made to set it to a pre-existing RepositoryID value. iv. Contained::name or the name attribute in any interface derived from Contained raises BAD_PARAM::3 when an attempt is made to set the name to a pre-existing name in the context. v. Contained::move and the move operation in all interfaces derived from Contained raises BAD_PARAM::2 or the BAD_PARAM::3 exceptions depending on which of the Repository ID or name clashes at the targetof the move. vi. Container::create_* operations and such operations in all interfaces derived from Container raise the BAD_PARAM::2 or the BAD_PARAM::3 when attempt is made to create things with clashing RepositoryIDs or names respectively. vii. InterfaceDef::base_interface attribute raises BAD_PARAM::3 if name clashes with existing names. viii. ValueDef:: supported_interface, base_value and abstract_base_value attributes raise the BAD_PARAM::2 or BAD_PARAM::3 exceptions on Repository ID clash or name clash respectively. This seems to form a firm and consistent foundation on which these issues can be resolved. Revised Text: Actions to be taken: November 7, 1997: received issue