Designing SCOadmin object service agents

Error management policy

For an overview of the SCOadmin error handling mechanism, see ``About SCOadmin error handling''. The following points define the current policy for dealing with errors and error stacks.

The following is a sample error stack returned from data base code in custom(ADM):

      {Open of data file for database "system" failed}
      {Open of database file "" failed}
      {Permission denied}

Error checking

The Server API takes care of a lot of the error handling which needs to take place in an OSA. Whenever an error is encountered, in the Server API or the OSA, the code will push the error onto a known ``error stack'' for future use by the Server API or the invoker of the Server API. The OSA writer will need to keep track of the following errors and report them to the Server API when they are encountered.

During Validation Stage

The Server API does some minor error checking on the arguments passed to it. Most of the error checking must be done by the OSA. The Server API will generate errors for:

During Application Stage

When an OSA invocation includes a list of object instances, Server API breaks it down in the application stage and processes each object instance individually. Each execution procedure should perform its intended application as a whole or not at all.

Those that are run per attribute should just be concerned whether there will be any errors effecting the modification of that one attribute. If there are none, then the application of the attribute's change can be completed. Otherwise the application of the attribute's change should not be attempted.

Those that are run per object should be concerned whether they can complete the entire operation without error or not. If the entire operation can be completed, only then should it be done. If any error would occur then the entire application should be aborted and the error returned.

The execution procedures should return one of the following errors at the top of the error stack (other messages can be placed lower on the stack):

The invoker does not have permission to run the specified operation.

The class is asked to create an object that already exists.

The class encounters an otherwise unspecified error in a get operation.

The class encounters an otherwise unspecified error in a set, replace, replaceWithDefault, add, or remove operation.

The value passed to an action in a argument is illegal or out of bounds.

The value passed to an operation or filter in an attribute is illegal or out of bounds.

The value passed to an action does not exist, or has no meaning.

The value action type passed to an action is unrecognized.

The filter function is unrecognized, a value is out of bounds, or otherwise meaningless.

The named object instance violates the naming rules.

An operation (not create) asked to run on a non-existent object.

operation asked to base new object instance on a non-existent object.

A failure occurs because of a resource limitation.
These can be generated by these commands:
   ErrorPush errStackVar throw messageId [argList]		Tcl
   ErrorPush(errStatus_cl *, const intlMsg_t *, ...)	C/C++
Any execution procedure returning and error stack without one of the previous errors at the top of the error stack will have the default message: SCO_OBJECT_LAYER_ERR_PROCESSING_FAILURE placed on the top of the stack. See Error(TCL_ADM) or Error(S_ADM) for more information.
Next topic: Execution procedure data structures
Previous topic: Return Value Structures

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003