Error Handling
Each method of the eXDI interfaces returns the data type HRESULT. For each of them, there is a defined set of values, known as standard errors, which correspond to behaviors defined by Platform Builder. Those values enable predefined behavior for handling these standard errors, but the driver can also return non-standard error values. Any client can get a textual description of the errors using GetErrorDescription. Platform Builder normally handles the standard errors.
In the case of non-standard errors, a more specific error code can be given, and Platform Builder will display the description in a message box.
GetErrorDescription assumes that one code corresponds to only one description string, and does not vary with context, so there is no assumption made concerning the sequence of calls in which GetErrorDescription is made.
In case of a communication error (eXDI_E_COMMUNICATION) or concurrent access error (eXDI_E_USEDBYCONCURRENTTHREAD), Platform Builder will try the same request every 300 ms, for 15 seconds — time in calls excluded. If this time passes without successfully making the request, Platform Builder displays a message box asking the user which action to take; for example, Cancel or Retry. In the case of an unexpected error, Platform Builder immediately queries the user what action to take, Cancel or Retry. But in case of a retry, it insures a minimum delay of 300 ms between each call.
eXDI defines its own set of exception code and descriptions. This set should be constant during a debugging session with a specific microprocessor. The debugger client normally requests the code and description table once after connecting to the driver. New code should not collide with the pre-defined set within Platform Builder, and it would be ignored if a collision occurred.
Platform Builder defines exception filtering. The eXDI API does not define any filtering but your eXDI implementation should, especially if the hardware supports it. Ideally, your driver would individually filter each exception captured by the probe. One of the advantages of this is that it enables hardware and kernel co-debugging. This would however require two instances of Platform Builder.
There are some cases when the eXDI driver may generate its own exceptions. Those accidental exceptions should be silent. eXDI should intercept these exceptions and convert them to HRESULT failure so that the inner workings of the probe are transparent to its clients.
It is highly recommended that you implement all the eXDI methods. There are a number of methods intended for you to develop that may not be used by Platform Builder or eXDI directly, but may be used by generic plug-ins.
See Also
Last updated on Friday, October 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.