| Previous | Table of Contents | Next |
This sub clause describes the way that Exceptions are organized in the MOF to IDL mapping. These exceptions are raised in
a variety of CORBA interfaces, including:
• Reflective interfaces: (see 10.2.2, “Reflective::RefBaseObject (abstract),? on page 250, 10.2.3, “Reflective::RefObject (abstract),? on page 254, 10.2.4, “Reflective::RefAssociation (abstract),? on page 265, 10.2.5, “Reflective::RefPackage (abstract),? on page 269.
• Model interfaces (see 7.4, “MOF Model Classes,? on page 41 and 7.5, “MOF Model Associations,? on page 85).
•
Specific interfaces produced by the mapping templates (see 9.8, “IDL Mapping Templates,? on page 202).
The exceptional conditions that arise in the context of the MOF to IDL mapping are classified into 5 groups:
1. Structural errors - this group covers those situations where the basic structural consistency rules for the metadata are (or would be) violated. For example, when there are too many or too few elements in a collection value.
3. Usage errors - this group covers those situations where a client tries to use the MOF interfaces in a meaningless way. For example, giving a ‘position’ for a collection element that is outside of the collection bounds.
4. Reflective errors - this group covers errors that can only occur when using the Reflective interfaces. For example, calling “refInvokeOperation? on an Attribute. These errors are the notional equivalent of runtime type errors.
5. Semantic errors - this group covers errors not covered above (i.e., implementation specific errors).
2. Constraint errors - this group covers violations of metadata consistency rules specified in the metamodel using
Constraints.
The complexity of the MOF means that the number of exceptional conditions is (at least in theory) unbounded. The precise set
of possible exceptional conditions for just one operation in the mapped interfaces can be very hard to define. Constraint
and Semantic errors are particularly difficult to tie down. Furthermore, including lots of exceptions in an IDL operation
signature can make client code inordinately complex.
To solve these problems, the MOF IDL mapping defines the MofError exception that covers most of the exceptional conditions
that might arise.
struct NamedValueType { wstring name; any value;
};typedef sequence < NamedValueType > NamedValueList;exception MofError {
wstring error_kind;RefBaseObject element_in_error;NamedValueList extra_info;wstring error_description;
};
The fields of the MofError exception are defined as follows:
• error_kind is a wide string that denotes the particular kind of exceptional condition that is being raised. The formation of values for this field is discussed below.
• element_in_error is the DesignatorType for the object or feature that is deemed to be in error for this error condition. The detailed specifications of the error conditions below define which meta-object should be returned in each case. In situations where no M2-level meta-objects are available, this field may contain a nil object reference.
• error_description is a human readable diagnostic message in a wide string. The contents of this field are not specified by this document.
• extra_info is a list of name / value pairs that provides the client with extra information about the error condition.
The list consists of zero or more standardized name / value pairs, followed by any implementation specific pairs. For the standardized part of the list, the sequence of the pairs and the values (including casing) of the names are mandatory. This allows clients to extract list elements by position or by matching names. It is recommended that implementors take the same approach for the implementation specific part of the list.
NOTE: The standardized name / value pairs for the extra_info field represent a compromise between the anticipated cost of
implementation and the provision of useful information to the caller. Implementors are encouraged to provide additional information.
Similarly, implementors are encouraged to provide detailed and informative diagnostics in the error_description field.
The values of the error_kind field or MofError are structured using Java’s reversed domain name syntax:
“org.omg.mof:structural.composition_cycle?
“au.edu.dstc.mofamatic:botched_assertion?
The values for each group of errors are as follows:
Structural and Reflective errors: the prefix “org.omg.mof:? followed by either “structural.? or “reflective.? and then the
specific error name in lowercase with underscores between words. These values are defined as constants in the IDL for the
Reflective module.
Constraint errors: the IDL prefix for the metamodel (if any), followed by “:constraint.? followed by the qualified constraint
name using the Format2 convention. For example, a Constraint named “MyConstraint? declared in “PackageA::ClassB,? the error
kind string value is:
“:constraint.package_a.class_b.my_constraint?
or with an IDL prefix of “com.acme?
it is:
“com.acme:constraint.package_a.class_b.my_constraint?
See
“Constraint Template? on page 245 for the definitive specification.
• Usage errors: not applicable. None of these error conditions are signalled using MofError.
• Semantic errors: an implementation specific prefix, followed by “:semantic.? followed by an implementation specific string. It is strongly recommended that the implementation specific part follow the conventions above (i.e., reverse domain names, all lowercase, periods for qualification and underscores between words).
All structural errors are signalled using MofError. With the exception of “Underflow,? the consistency rules covered by the
structural errors are either pre- or post-conditions on operations.
The MOF IDL mapping defines the structural errors as defined in the table below.
Structural error |
“Element_in_error? |
Standard “extra_info? |
Description |
||
| Underflow | Attribute, Parameter, or Association End defining the Multiplicity that is violated. | none | "Underflow" arises when a collection or projection contains fewer values than is required by the corresponding Multiplicity.lower. Note that the evaluation “underflow? is context dependent. For an operation that takes a collection value as a parameter, or whose net effect is to decrease the number of elements in a multi-valued Attribute or a projection of a Link set, “underflow? is treated as an immediate constraint. In other cases, “underflow? is treated as a deferred constraint. | ||
| Overflow | Attribute, Parameter, or Association End defining the Multiplicity that is violated. | none | "Overflow" arises when a collection or projection contains more values than is allowed by the corresponding Multiplicity.upper. | ||
| Duplicate | Attribute, Parameter, or Association End defining the Multiplicity that is violated. | “duplicate? : Any(<Value>) A value that appears more than once in the unique collection / projection. | "Duplicate" arises when a collection or projection whose corresponding Multiplicity.is_unique is true contains duplicate values. For example, when two or more values at different positions in the collection or projection that are “equal? according to the definitions in 8.4, “Semantics of Equality for MOF Values,? on page 140. | ||
| Reference Closure | Reference for which the closure rule is violated. | “external? : Any(<Instance>) An Instance that violates a closure rule with respect to the Association being updated. | "Reference Closure" can arise when an Association extent contains a link for an Instance object belonging to another outermost Package extent. More particularly, this happens when the Instance object's M2-level Class (or a super-Class ancestor) has a Reference to the M2-level Association. See 8.11.1, “The Reference Closure Rule,? on page 153. | ||
| Composition Closure | Attribute or Association for which the closure rule is violated. | “external? : Any(<Instance>) An Instance that was passed as or within in an operation parameter that violates the closure rule. | "Composition Closure" arises when an Instance object is member of a composite that crosses an outermost Package extent boundary. See 8.11.2, “The Composition Closure Rule,? on page 155. |
Structural error |
“Element_in_error? |
Standard “extra_info? |
Description |
||
| Supertype Closure | Class of the object that cannot be created. | none | "Supertype Closure" arises when a client attempts to create an Instance object in a Package extent that does not support its M2-level Class. See 9.3.11, “The Supertype Closure Rule,? on page 182. | ||
| Composition Cycle | Attribute, Reference or Association that is being updated to form the cycle. | “cyclic? : Any(<Instance>) A composite Instance passed as or within a parameter that would become cyclic as a result of this operation. | "Composition Cycle" arises when an Instance object is a component of itself via one or more relationships defined by composite Associations or composite Attributes. | ||
| Nil Object | Reference or Association End for which the nil object reference was supplied. | none | "Nil Object" arises when an Association operation is passed a CORBA nil object reference. | ||
| Inaccessible Object | Attribute, Parameter, Reference, or Association End for which the inaccessible object was detected. | “inaccessible? : Any(<RefObject>) An Instance object that was inaccessible. | "Inaccessible Object" arises when an operation tries to use an Instance object only to find that it is currently inaccessible. | ||
| Invalid Object | Attribute, Parameter, Reference, or Association End for which the invalid object was detected. | “invalid? : Any(<RefBaseObject>) An object reference for a MOF meta-object that does not exist. | "Invalid Object" can arise when an object operation detects a reference for a nonexistent (i.e.,deleted) object. | ||
| Already Exists | Class of the object that already exists. | “existing? : Any(<Instance>) The pre-existing singleton Instance object for the extent. | “Already Exists? arises when a client attempts to create a second Instance object for an M2-level Class with “isSingleton? of true. |
NOTE: There are no mandatory ‘extra_info’ pairs for "Overflow" and "Underflow" because the error conditions occur in such
a wide range of contexts that it is difficult to come up with a set that is universally applicable. Vendors are encouraged
to innovate by defining non-standard pairs.
The following IDL constants define the corresponding error_kind strings.
const string UNDERFLOW_VIOLATION = "org.omg.mof:structural.underflow";
const string OVERFLOW_VIOLATION = "org.omg.mof:structural.overflow";
const string DUPLICATE_VIOLATION = "org.omg.mof:structural.duplicate";
const string REFERENCE_CLOSURE_VIOLATION = "org.omg.mof:structural.reference_closure";
const string SUPERTYPE_CLOSURE_VIOLATION = "org.omg.mof:structural.supertype_closure"; const string COMPOSITION_CYCLE_VIOLATION
= "org.omg.mof:structural.composition_cycle"; const string COMPOSITION_CLOSURE_VIOLATION = "org.omg.mof:structural.composition_closure";
const string NIL_OBJECT_VIOLATION = "org.omg.mof:structural.nil_object"; const string INACCESSIBLE_OBJECT_VIOLATION = "org.omg.mof:structural.inaccessible_object";
const string INVALID_OBJECT_VIOLATION = "org.omg.mof:structural.invalid_object"; const string ALREADY_EXISTS_VIOLATION = "org.omg.mof:structural.already_exists";
Constraint errors occur when a consistency rule is defined as a Constraint in the metamodel. All Constraint errors are signalled by raising MofError. The fields of the MofError exception are defined as follows:
• The error_kind string is defined by the IDL mapping rules (see 9.8.16, “Constraint Template,? on page 245).
• The element_in_error is the designator for the ModelElement whose Constraint has been violated. In the case of Constraint on a DataType, the designator is the Parameter or Attribute for the context in which the erroneous DataType instance occurred.
• The value of the extra_info field is implementation specific. Where possible, the implementation should provide the constrained object(s) or value(s) for which the constraint is violated.
Constraints can be defined with an “evaluationPolicy? of “immediate? or “deferred.? In the former case, violations of the
rule are likely to be reported when a constrained object is created or updated. In the latter case, violations are likely
to be reported when deferred Constraint checking is triggered.
NOTE:
The above statements assume that constraint checking is implemented according to the spirit of 8.8, “Extents,? on
page 145
.
The Semantic error group is the “catch all? for otherwise unclassified implementation specific errors. Semantic errors are
signaled by raising the MofError exception when appropriate. Possible sources of this error include:
• additional metadata consistency rules that are not specified in the metamodel,
• implementation specific access control violations,
• resource limitations in a metadata server, and
• internal errors in a metadata server. The values of the MofError exception fields for a Semantic error are implementation
specific:
• Implementors should define a unique string for the error_kind field to distinguish the different kinds of Semantic error. These values should conform to the pattern described in 9.4.1, “Error_kind string values,? on page 185.?
• The values and meanings of the element_in_error and extra_info fields should be defined as appropriate.
The Usage error group indicates inappropriate use of the MOF IDL interfaces. They can arise when a client is using either
the Reflective interfaces, or the interfaces generated by the IDL mapping.
The Usage errors are signalled using their own exceptions.
Table 9.1 - Usage Exceptions
Usage Exception |
Arguments |
Description |
|||
| NotFound | none | NotFound is raised by modify and remove operations on multi-valued Attributes, References, and Associations when the argument that should identify the member or link to be removed does not match any value that is currently there. | |||
| NotSet | none | NotSet is raised when a client attempts to read the element value of an optional collection (i.e., one with bounds of [0..1]) when the collection is empty. | |||
| BadPosition | none | BadPosition is raised when a positional add, modify, or remove operation is supplied with a ‘position’ argument whose value is out of range. The collection’s current size is returned in the exception’s ‘current_size’ field. This will be 0 if the collection is empty, 1 if it contains a single member, and so on. |
NOTE: The members of a collection value containing size elements are numbered {0, 1,... size - 1} for the purposes of the
positional update operations. The positional modify / remove operations are defined to modify or remove the member indexed
by the position (i.e., position values in the range 0 to size - 1 inclusive are valid). The positional add operation is defined
to insert a member before the member indicated by the position. In this case, position values in the range 0 to size inclusive
are valid, with size meaning “insert at the end.?
The IDL declarations for the Usage error exception are as follows:
exception NotFound {};
exception NotSet {};
exception BadPosition {
unsigned long current_size; };
Reflective error conditions occur exclusively in operations in the Reflective interfaces. They occur when a Reflective operation
is invoked with parameters that contradict the target object's description in the metamodel. When the client uses interfaces
generated by the IDL mapping, the static type checking based on the specific IDL signatures should prevent the equivalent
errors from occurring.
In most cases, the MofError exception is used to signal reflective errors. Table 9.2 lists the Reflective errors that are
signalled using MofError, along with the MofError field specifications and descriptions. All are pre-conditions for the respective
operations.
Table 9.2 - Reflective Errors signalled using MofError Table 9.2 - Reflective Errors signalled using MofError
Reflective error |
“Element_in_error? |
Standard “extra_info? |
Description |
||
| Invalid Designator | ModelElement that is invalid | none | “Invalid Designator? arises when a “feature? parameter: • is not a Model::ModelElement, or • does not denote an accessible, non nil CORBA object. | ||
| Wrong Designator Kind | ModelElement that has the wrong kind | none | “Wrong Designator Kind? arises when the supplied designator has an inappropriate most-derived type. For example, when a Model::Attribute is supplied where a Model::Operation is required. | ||
| Unknown Designator | ModelElement that is not known. | none | “Unknown Designator? arises when the supplied designator does not belong in this context. For example, when a Model::Attribute is not a member of this Instance’s Class or its superClasses. | ||
| Abstract Class | Class that is abstract. | none | “Abstract Class? arises when a client calls “refCreateInstance? for a Class that is defined as abstract. | ||
| Not Changeable | ModelElement that has “isChangeable? = false | none | “Not Changeable? arises when an update operation is attempted on something that is defined by the metamodel to be not changeable. | ||
| Not Navigable | AssociationEnd that has “isNavigable? = false | none | “Not Navigable? arises when RefAssociation operations are attempted for an AssociationEnd that is defined by the meta-model to be not navigable. | ||
| Not Public | ModelElement that has “visibility? = “private_vis? or “protected_vis? | none | “Not Public? arises when an operation is attempted for a “private? or “protected? feature. | ||
| Wrong Scope | Attribute or Operation with “scope? = “instance_level? | none | “Wrong Scope? arises when an attempt is made to use an instance-level Attribute or Operation from a Class proxy object. |
Reflective error |
“Element_in_error? |
Standard “extra_info? |
Description |
||
| Wrong Multiplicity | Reference or Attribute used in error. | none | “Wrong Multiplicity? arises when a reflective operation is requested where the corresponding specific operation does not exist for this feature’s multiplicity. For example: • a member update on a [0..1] or [1..1] feature, • a unset on a feature that is not [0..1], • an add_value_at on an unordered feature. | ||
| Wrong Type | Attribute, Reference, AssociationEnd, or Parameter for the value that is in error. | “invalid_value? : Any The value or object whose type is incorrect in this context. (The first version is used when the value in error was passed as an Any, and the second when it was passed as a RefObject.) “expected_type? : Any(TypeCode) The CORBA TypeCode that the value should have been. | “Wrong Type? arises when a RefObject or an Any value has the wrong type for context in which it was supplied. For example; • A RefObject whose most derived type is incorrect; for example, has the wrong M2level Class or is a Class proxy instead of Instance, or vice versa. • An Any value that contains a single value where a sequence is required, or vice versa. • An Any value that contains a single value or sequence of values of the wrong CORBA type. | ||
| Wrong Number Parameters | Class or Operation for which the wrong number of actual parameters was supplied. | “number_expected? : Any(Unsigned Long) The expected number of actual parameters. | “Wrong Number Parameters? arises when a client calls “refCreateInstance? or “refInvokeOperation? with too few or too many parameters. | ||
| Invalid Deletion | A nil object reference | none | “Invalid Deletion? arises when a client calls “refDelete? on a meta-object that cannot be deleted this way; that is, an Association object, a Class Proxy object, or a dependent Package object. |
The following IDL defines the error_kind strings for the above Reflective errors:
const string INVALID_DESIGNATOR_VIOLATION = "org.omg.mof:reflective.invalid_designator";
const string WRONG_DESIGNATOR_DESIGNATOR_VIOLATION = "org.omg.mof:reflective.wrong_designator_kind";
const string UNKNOWN_DESIGNATOR_VIOLATION = "org.omg.mof:reflective.unknown_designator";
const string ABSTRACT_CLASS_VIOLATION = "org.omg.mof:reflective.abstract_class";
const string NOT_CHANGEABLE_VIOLATION = "org.omg.mof:reflective.not_changeable";
const string NOT_NAVIGABLE_VIOLATION = "org.omg.mof:reflective.not_navigable"; const string NOT_PUBLIC_VIOLATION = "org.omg.mof:reflective.not_public";
const string WRONG_SCOPE_VIOLATION = "org.omg.mof:reflective.wrong_scope"; const string WRONG_MULTIPLICITY_VIOLATION = "org.omg.mof:reflective.wrong_multiplicity";
const string WRONG_TYPE_VIOLATION = "org.omg.mof:reflective.wrong_type"; const string WRONG_NUMBER_PARAMETERS_VIOLATION =
"org.omg.mof:reflective.wrong_number_parameters"; const string INVALID_DELETION_VIOLATION = “org.omg.mof:reflective.invalid_deletion?;
Other Exception
There is one exception to this — when an Operation defined in the metamodel raises an Exception that is also defined in the
metamodel; see below.
The OtherException exception is raised when a call to “refInvokeOperation? results in an error condition that corresponds
to an M2-level Exception defined for the Operation in the metamodel.
exception OtherException { DesignatorType exception_designator; ValuesType exception_args;
};
The arguments to the OtherException exception are as follows:
• exception_designator gives the designator for the M2-level Exception raised.
• exception_args is an ordered list of CORBA Any values that represent the arguments of the Exception raised. The encoding of this field is defined in the specification of the “refInvokeOperation? on page 263.
NOTE: When an error condition could be expressed as either a Reflective error or a Structural error, the latter takes precedence.
For example, if one end of Link in a call to “refAddLink? is a nil object reference, this should be signalled as “Nil Object?
rather than “Wrong Type.?