Introduction

To handle expection, the current simple implementation includes two error state variables:

"state" (boolean flag if error occurred)
"message" (string with error message)

These variables are automatically connected to the control systen in this format:

/Devices/{AliasName}/message
/Devices/{AliasName}/status

In this implementation a user/application can report an exception by calling reportException of DeviceModule with an exception string. The reportException packs the exception in a queue and the blocks the thread. This queue is processed by an internal function handleException which updates the DeviceError variables (status=1 and message="YourExceptionString") and tries to open the device. Once device can be opened the DeviceError variables are updated (status=0 and message="") and blocking threads are notified to continue. It must be noted that whatever operation which lead to exception e.g., read or write, should be repeated after the exception is handled.

Checkout testExceptionTest.cc under tests/executables_src to see how it works.

DataValidity

ChimeraTK supports a DataValidity flag, which is attached to all TransferElements. It can have the two states ok and faulty. This flag is propagated through ApplicationModules automatically. If a faulty flag has been received in an read operation of any input, all subsequent write operations will set the faulty flag as well, until the flag is back to the ok state for all inputs.

Note that if the data is distributed through a triggered FanOut (i.e. variables from device is connected to other variables through a trigger, the usual way for poll-type variables) the data read from the receiving end of the variable cannot be considered valid if the DataValidity is faulty.

Additionaly, a change of to a faulty validity state will signal the availability of new data on those variables, which is to be considered invalid.