Error Types to Consider

When an error occurs, call the FFSTProbe function to log the error. The following examples describe several error types you should consider when you instrument your code and the types of data to capture for the error:

Error return

Determine the severity of an error so that you call the FFSTProbe function only when the error return indicates a serious problem. When a calling program has a significant failure that causes an error return, the program calls FFSTProbe. Be careful not to cause a "cascade" of calls to FFSTProbe as the system passes error returns back up through a set of higher level function calls.

Failure-related data may include:

• Return code
  
• Input parameters to the function
  
• Returned values from the function
  
• Any internal variables that determine or affect the erroneous results
Damaged data structures
Product data structures can become damaged with data that is not valid. To capture data for this type of error during normal processing, your code could have a method for periodically checking important internal data structures. Such logic is an important step toward improving the reliability and availability of the product.

Failure-related data may include:

• Data structures
  
• Historical information that indicates when your code found the product data structure to be correct
  
• General system data showing other programs in use by the system when the error occurred.
Time-outs and detected hangs
To detect time-outs and hangs, design your code to sense how long a given request should take.

Failure-related data may include:

• Current time-out values
  
• Any state information that describes what the timed-out function is currently doing
  
• States of resources that may relate to the time-out or hang
  
• Historical information that describes what the timed-out function had been doing before the error occurred.
Slow performance of a service
In order to detect a slow performance condition, design code to sense how long a given service should take before calling FFSTProbe.

Failure-related data may include:

• Internal resource states that may relate to the slow performance of the service
  
• Historical information that indicates who has been using that service and what requests the user made of the service.
Traps
It is difficult to detect a failure within a product and determine its cause after an exception management routine has received control. Well-designed and instrumented code can detect a failure before exception management routines get control.

Failure-related data may include:

• Exception blocks that contain the hardware state when the trap occurred
  
• Context data indicates what was being run when the trap occurred (for example, call stacks or internal state variables)

---

[Back: Deciding What Data You Want to Collect]
[Next: Ways to Collect Data]