Issue 2191:  Exception to indicate no corresponding "specific" operation (mof-rtf)
Source:  (, )
Nature:  Revision
Severity:  Minor
Summary: Summary: Issue 968 states that there is a need for a new exception
 called (say) "AbstractType" which is raised by create_instance() when
 it is invoked for an abstract Class.  This exception would only be
 raised by the create_instance() operation when when there is no
 corresponding "specific" operation.  There are many other operations
 in which this general condition can occur.  Section 5.4.2, states that
 the CORBA system Exception NO_IMPLEMENT should be raised in the case
 where modify or delete operations are not available.  This needs to be
 handled more consistently.
 
 
 

Resolution: closed, resolved
Revised Text: 
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue
Discussion: 
Discussion : Good Idea, Can you make a concrete proposal for us to look at.
For RefObject:
If all_objects is called for an abstract Class with include_subtypes false, should this oper-ation
fail, as it is meaningless? Probably should raise AbstractClass exception (which al-ready
exists as a result of another issue).
E.g. if an attribute is readonly, all of the set_value, add_value should fail.
If an attribute is 0..1 or 1..1, then the add_value, etc operations should fail
If an attribute is not ordered, then the add_before and add_at etc should fail
If we introduce an unset_value operation (as part of another issue), then that operation
should fail if the value is singleton.
For RefAssociation:
If we decide to make derived Associations readonly (another issue), then all of the add_link
etc operations of a readonly association should fail.
If there is no ordering, then the add_link_before should fail.
There appears to be a need for Reflective exceptions:
* ReadOnly to be raised if anyone tries to set/add/modify/remove readonly values
* NotCollection to be raised if anyone tries to add/modify/remove single or optional values
(i.e. anything with multiplicity.upper = 1)
* NotOrdered to be raised if anyone tries to do *_before and *_at operations on
non-ordered collections
* CannotUnset to be raised if anyone tries to unset things that are not unset-able
All of the above would have a DesignatorType field for the meta-information that tells us
that they did an illegal action.
If we do all of this, then parts of Section 6.2.1, “Reflective Argument Encoding Patterns.,” on page 6-3 will need to be revised to remove the text about raising
NOT_IMPLEMENTED.
Implementation: These conditions are variously signalled using MofError("Wrong
Multiplicity", "Not Changeable") as indicated in the revised de-scriptions
in Section 6.2, “The Reflective Interfaces,” on page 6-3.
Section 6.2.1, “Reflective Argument Encoding Patterns.,” on
page 6-3 has been rewritten, and NO_IMPLEMENT is not men-tioned.
Implementation: RefObject::all_objects(false) is described as returning an empty set
rather than raising an exception if the Class is abstract. Done. [SC]
End of Annotations:=====
Return-Path: <crawley@dstc.edu.au>
To: mof-rtf@omg.org, issues@omg.org
Subject: Issues with the MOF Reflective interfaces
Date: Sat, 07 Nov 1998 02:04:02 +1000
From: Stephen Crawley <crawley@dstc.edu.au>


This message contains a set of issues that DSTC have discovered while
implementing the MOF Reflective interfaces.  Don't panic.  They are
all "minor" :-)

Credit for finding them and carefully documenting them is due to
Douglas Kosovic.

-- Steve

Subject: Exception to indicate no corresponding 'specific' operation
Source: DSTC (Douglas Kosovic, douglask@dstc.edu.au)
Nature: Revision
Severity: Minor

Summary: Issue 968 states that there is a need for a new exception
called (say) 'AbstractType' which is raised by create_instance() when
it is invoked for an abstract Class.  This exception would only be
raised by the create_instance() operation when when there is no
corresponding 'specific' operation.  There are many other operations
in which this general condition can occur.  Section 5.4.2, states that
the CORBA system Exception NO_IMPLEMENT should be raised in the case
where modify or delete operations are not available.  This needs to be
handled more consistently.

Additional text:

It is suggested that there one exception that covers all of these
cases including those not currently documented. For example:

  exception NoAnalogOperation {};