Error-Handling Functions

Silk Performer offers several functions to handle unexpected situations during a load or verification test. Unexpected situations mostly end up in warnings or errors.

A commonly used mechanism to query the current state during a virtual user run is the last error. The last error describes not more than the last error that occurred.

If several errors occurred at about the same time, only the last one is stored and can therefore be retrieved. Silk Performer goes a step beyond and lets the user access not only the last error but also some relevant errors that occurred before the last error. Each virtual user holds a so-called error stack where it stores errors for each erroneous function call.

The error stack is per function call and enables you to retrieve not only the last error but all errors of one erroneous function call. A next function call clears that error stack of the last function.

To step through the error stack the following error functions are provided:

• GetFirstError: Retrieves the first error from the error stack.
• GetNextError: Retrieves the next error from the error stack.
• GetLastError: Retrieves the last error from the error stack.

An error consists of an error code, a facility and a severity.

The error facility is provided as a way to categorize errors in respect to the area or module in which they originate.

To retrieve further information about a particular error the following functions are provided:

• GetErrorCode: Retrieves error number (code).
• GetErrorFacility: Retrieves the name of the severity level.
• GetErrorSeverity: Retrieves the severeness level of an error.
• GetErrorMsg: Retrieves the error message corresponding to an error code.

To create an error code and raise an error use the following functions:

• CreateErrorCode: Creates an error code using severity, facility, and error number within the facility as parameters.
• RaiseError: This function can be used to raise an error.

Silk Performer offers the possibility to redefine (overwrite) the default severity of an error. This is useful in several scenarios. For example, the simulator is reporting an error with severity SEVERITY_ERROR but the user does not want to consider it to be a real error. In this case the user is able to overwrite the default severity with SEVERITY_INFORMATIONAL. This affects the simulator also, which does not increase the error count if this particular error occurs.

Functions, which allow severity manipulations, are:

• ErrorAdd: Defines the severity of a particular problem.
• ErrorRemove: Removes the custom severity definition for a particular problem.

Facility values: