OSID Specifications
meta package
Version 3.0.0
Release Candidate Preview
MetaOSID Errors

Errors are specified in each method specification. Only the specified errors are permitted as error conditions in OSID method contracts with exceptions noted in the descriptions below. Provider Contract errors are never specified but may be returned at any time by an OSID Runtime. An OSID Provider implementation is only permitted to return those errors specified in a method contract however, some Consumer Contract errors may be automatically handled in an OSID Runtime.

Errors should result when the contract of the interface as been violated or cannot be fulfilled and it is necessary to disrupt the flow of control for an OSID Consumer. Different errors are specified where it is forseen that an OSID Consumer may wish to execute a different action without violating the encapsulation of internal OSID Provider operations. Such actions do not include debugging or other detailed information which is the responsibility of the OSID Provider to manage. As such, the number of errors defined across all the interfaces is kept to a minimum and the context of the error may vary from method to method in accordance with the OSID specification.


User errors are only permitted where specified in method signatures and should be handled directly by a consumer application.


Attempt to add an object that already exists. Some providers may enforce a uniqueness requirement on one or more data elements not specified in the interface while others may permit it. The places where this error is required to be returned relate to indices or other pseudo-identifiers specified in the interface.


The given Id or other identifier was not found. Where a single object is specified as a return value in response to lookup by an identifier, this error must be returned if not found. In methods that specify an OsidList or other grouping as a return value, an empty list should be returned where this error is not specified.


An authorization failure occurred. This error should be returned when the user cannot perform an operation. Generally, this is deteremined by using an Authorization service contained within a service. This error implies that if a user was granted authorization, the operation could succeed. Permission problems in the a system or database, for example, may imply a configuration or operational problem not resulting from a user authorization and should result in a different error condition.


Operational errors result from failures in the system. These errors are only permitted where specified and should be handled directly by the consumer application.


An error occurred configuring the OSID implementation during initialization and the implementation cannot be used. The configuration should be verified against the provider specifications.


A problem occurred in system execution.


An error occurred within a transactional element while committing a transaction. It isn't known what transactional element caused the failure.


Errors in programming resulting from an incorrect use of the OSIDs. Application code should be checked for accuracy. These errors should be avoided by using the defined interoperability and flow control tests.


Method has been executed at an inappropriate time such as re-initializing a manager, accessing a resource after it has been closed, opening a new transaction while one is already in progress, or accessing elements when no more exist.


A supplied argument is invalid. This may be due to a data violation that should be checked against the appropriate Metadata object or specification for validity before use. These errors may also be returned where not specified in cases where an OSID parameter is specified to have a restricted set of values not enforced by the language environment, such supplying a negative number for a cardinal parameter.


A method not defined in the interface was invoked. This error is not used in the method specification but may occur any time an undefined method is invoked, as permissable by the language environment.


The value cannot be changed. The metadata for the data element or property should be checked to avoid this error. This condition is the result of supplying a value to an OsidForm where the provider does not implement or permit changes to the element.


A null argument was provided. This error can only result for methods that define parameters. Consumers are not permitted to supply null values for method arguments.


This method has not been implemented by this provider. The appropriate boolean test to indicate that this provider does not support this method should be supplied by the provider and checked by the consumer to avoid this error. This error can only result for methods whose compliance is optional.


The given Type or requested operation is not supported. The appropriate interoperability test should be used to verify the use of any Type to avoid this error.


Errors in programming resulting from an incorrect implementation of the OSIDs. These errors are not used in the method specifications as they result only from an implementation problem detected by the OSID Runtime environment or unit testing harness. Consumers receiving these errors should consider the provider faulty. Providers do not return these errors directly from their respective implementations.


Implementation has incorrect behavior with respect to profile or other interoperability methods.


Implementation returned an undefined error.


Implementation returned an invalid value.


Method is missing from the interface implementation.


Implementation returned a null value where an actual value was defined.