ChimeraTK-ApplicationCore  04.01.00
Tests::testExceptionHandling Namespace Reference

Typedefs

using Fixture = FixtureWithPollAndPushInput< false >
 
using Fixture_initHandlers = FixtureWithPollAndPushInput< false, true >
 
using Fixture_secondDeviceBroken = FixtureWithPollAndPushInput< false, false, true >
 

Functions

 BOOST_FIXTURE_TEST_CASE (B_2_1, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_2_poll, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_2_push, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_3, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_3_TriggerFanOut, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_blocking, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_nonBlocking, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_any, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_latest, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_ThFO, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_TrFO, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_1_nonBlocking, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_1_latest, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_2, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_4_3, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_5, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_2_6, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_3_3, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_3_5, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_2_5, Fixture)
 
 BOOST_FIXTURE_TEST_CASE (B_3_1_1, Fixture_initHandlers)
 
 BOOST_FIXTURE_TEST_CASE (B_3_1_2, Fixture_initHandlers)
 
 BOOST_FIXTURE_TEST_CASE (B_3_1_3, Fixture_initHandlers)
 
 BOOST_FIXTURE_TEST_CASE (B_3_1_4, Fixture_initHandlers)
 
 BOOST_FIXTURE_TEST_CASE (B_4_1, Fixture_secondDeviceBroken)
 

Typedef Documentation

◆ Fixture

◆ Fixture_initHandlers

◆ Fixture_secondDeviceBroken

Function Documentation

◆ BOOST_FIXTURE_TEST_CASE() [1/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_1  ,
Fixture   
)

B.2.1

"The exception status is published as a process variable together with an error message."

Definition at line 46 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [2/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_2_poll  ,
Fixture   
)

B.2.2.2

"The DataValidity::faulty flag resulting from the fault state is propagated once, even if the variable had the a DataValidity::faulty flag already set previously for another reason."

TODO Set previous fault flag through Backend, and test inside TriggerFanOut (the latter needs the first)

Definition at line 84 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [3/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_2_push  ,
Fixture   
)

B.2.2.2

"The DataValidity::faulty flag resulting from the fault state is propagated once, even if the variable had the a DataValidity::faulty flag already set previously for another reason."

TODO Set previous fault flag through Backend, and test inside ThreadedFanOut and TriggerFanOut (as trigger).

Definition at line 126 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [4/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_3  ,
Fixture   
)

B.2.2.3

"Read operations without AccessMode::wait_for_new_data are skipped until the device is fully recovered again (cf. 3.1). The first skipped read operation will have a new VersionNumber."

Test directly inside ApplicationModule

Definition at line 165 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [5/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_3_TriggerFanOut  ,
Fixture   
)

B.2.2.3

"Read operations without AccessMode::wait_for_new_data are skipped until the device is fully recovered again (cf. 3.1). The first skipped read operation will have a new VersionNumber."

Test inside a TriggerFanOut. This is mainly necessary to make sure the ExceptionHandlingDecorator is used for variables inside the TriggerFanOut.

Definition at line 202 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [6/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_1_latest  ,
Fixture   
)

B.2.2.4.1

[After first skipped read operation in 2.2.4, the following] "non-blocking read operations (readNonBlocking() and readLatest()) are skipped and return false (= no new data), until the device is recovered".

This test is for readLatest().

Definition at line 467 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [7/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_1_nonBlocking  ,
Fixture   
)

B.2.2.4.1

[After first skipped read operation in 2.2.4, the following] "non-blocking read operations (readNonBlocking() and readLatest()) are skipped and return false (= no new data), until the device is recovered".

This test is for readNonBlocking().

Definition at line 434 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [8/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_2  ,
Fixture   
)

B.2.2.4.2

[After first skipped read operation in 2.2.4, the following] "blocking read operations (read()) will be frozen until the device is recovered."

Definition at line 498 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [9/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_3  ,
Fixture   
)

B.2.2.4.3

"After the device is fully recovered (cf. 3.1), the current value is (synchronously) read from the device. This is the first value received by the accessor after an exception."

Definition at line 529 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [10/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_any  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for readAny.

Definition at line 301 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [11/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_blocking  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for blocking read().

Definition at line 241 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [12/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_latest  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for readLatest().

Definition at line 333 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [13/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_nonBlocking  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for readNonBlocking().

Definition at line 271 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [14/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_ThFO  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for read() inside a ThreadedFanOut. (The ThreadedFanOut never calles the other read functions.)

Definition at line 363 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [15/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_4_TrFO  ,
Fixture   
)

B.2.2.4

"Read operations with AccessMode::wait_for_new_data will be skipped once for each accessor to propagate the DataValidity::faulty flag (which counts as new data, i.e. readNonBlocking()/readLatest() will return true (= hasNewData), and a new VersionNumber is obtained)."

This test is for read() inside a TriggerFanOut on the trigger variable.

Definition at line 400 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [16/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_5  ,
Fixture   
)

B.2.2.5

"The VersionNumbers returned in case of an exception are the same for the same exception, even across variables and modules. It will be generated in the moment the exception is reported."

Definition at line 564 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [17/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_2_6  ,
Fixture   
)

B.2.2.6

"The data buffer is not updated. This guarantees that the data buffer stays on the last known value if the user code has not modified it since the last read."

Definition at line 594 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [18/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_3_3  ,
Fixture   
)

B.2.3.3

"The return value of write() indicates whether data was lost in the transfer. If the write has to be delayed due to an exception, the return value will be true (= data lost) if a previously delayed and not-yet written value is discarded in the process, false (= no data lost) otherwise."

Definition at line 636 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [19/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_3_5  ,
Fixture   
)

B.2.3.5

"It is guaranteed that the write takes place before the device is considered fully recovered again and other transfers are allowed (cf. 3.1)."

Definition at line 660 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [20/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_2_5  ,
Fixture   
)

B.2.5

"TransferElement::isReadable(), TransferElement::isWriteable() and TransferElement::isReadonly() return with values as if reading and writing would be allowed."

Definition at line 688 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [21/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_3_1_1  ,
Fixture_initHandlers   
)

B.3.1.1

[The recovery procedure involves] "the execution of so-called initialisation handlers (see 3.2)."

B.3.2

"Any number of initialisation handlers can be added to the DeviceModule in the user code. Initialisation handlers are callback functions which will be executed when a device is opened for the first time and after a device recovers from an exception, before any application-initiated transfers are executed (including delayed write transfers). See DeviceModule::addInitialisationHandler()."

Definition at line 719 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [22/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_3_1_2  ,
Fixture_initHandlers   
)

B.3.1.2

[After calling the initialisation handlers are called, the recovery procedure involves] "restoring all registers that have been written since the start of the application with their latest values. The register values are restored in the same order they were written. Registers of the type ChimeraTK::Void are not written."

Definition at line 764 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [23/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_3_1_3  ,
Fixture_initHandlers   
)

B.3.1.3

[During recovery,] "the asynchronous read transfers of the device are (re-)activated by calling Device::activateAsyncReads()" [after the delayed writes are executed.]

Definition at line 835 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [24/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_3_1_4  ,
Fixture_initHandlers   
)

B.3.1.4

[As last part of the recovery,] "Devices/<alias>/deviceBecameFunctional is written to inform any module subscribing to this variable about the finished recovery."

Definition at line 871 of file testExceptionHandling.cc.

◆ BOOST_FIXTURE_TEST_CASE() [25/25]

Tests::testExceptionHandling::BOOST_FIXTURE_TEST_CASE ( B_4_1  ,
Fixture_secondDeviceBroken   
)

B.4.1

"Even if some devices are initially in a persisting error state, the part of the application which does not interact with the faulty devices starts and works normally."

Definition at line 906 of file testExceptionHandling.cc.