ExceptionHandling Spec: Changed specification for boost::numeric::bad_numeric_cast

* Added B.1.3 and B.1.4 : boost::numeric::bad_numeric_cast and boost::thread_interrupted are not treated
* Removed B.6 (behaviour for bad_numeric_cast)
* Removed C.2.8 (implementation for bad_numeric_cast)
* Re-numbered C.2.9 to C.2.8. It is the last section in C.2 and did not contain any anchors, so no references need to be changed.

doc/spec_exceptionHandling.dox

@@ -35,6 +35,8 @@ namespace ChimeraTK {
 - 1. All ChimeraTK::runtime_error exceptions thrown by device register accessors are handled by the framework and are never exposed to user code in ApplicationModules.
   - \anchor b_1_1 1.1 ChimeraTK::logic_error exceptions are left unhandled and will terminate the application. These errors may only occur in the (re-)initialisation phase (up to the point where all devices are opened and initialised) and point to a severe configuration error which is not recoverable. \ref comment_b_1_1 "(*)"
   - \anchor b_1_2 1.2 <b>Exception handling and DataValidity flag propagation is implemented such that it is transparent to a module whether it is directly connected to a device, or whether a fanout or another application module is in between.</b> This is the central requirement from which most other requirements are derived.
+  - \anchor exceptionHandling_b_1_3 1.3 boost::numeric::bad_numeric_cast exceptions are treated like  ChimeraTK::logic_error. They originate from picking the wrong data type in the program code or the configuration and are also not recoverable by re-opening the device.
+  - \anchor exceptionHandling_b_1_4 1.4 The only other exception allowed by the DeviceAccess::TransferElement specificaton is boost::thread_interrupted. It must not be caught by the exception handling decorator because it is used to cleanly shut down the application.
 
 \subsection spec_exceptionHandling_behaviour_runtime_errors Runtime error handling
 - \anchor b_2 2. When a ChimeraTK::runtime_error has been received by the framework (thrown by a device register accessor):
@@ -75,12 +77,6 @@ namespace ChimeraTK {
 \subsection spec_execptionHandling_behaviour_forced_recovery Forced Recovery
 - \anchor b_5 5. Any ApplicationModule can explicitly report a problem with the device by calling DeviceModule::reportException(). This allows the reinitialisation of a device e.g. after a reboot of the device which didn't result in an exception (e.g. because it was too quick to be noticed, or rebooting the device takes place without interrupting the communication).
 
-\subsection spec_exceptionHandling_behaviour_numeric_cast_errors Numeric cast error handling
-- \anchor b_6 6. If a boost::numeric::bad_numeric_cast is received
-  - 6.1 the exception is not reported to the device.
-  - 6.2 Write operations are skipped because the exception is happening in doPreWrite(). The return value of writeYyy() is true (data was lost).
-  - \anchor b_6_3 6.3 Read operations return with DataValidity::faulty.
-
 \subsection spec_execptionHandling_behaviour_comments (*) Comments
 
 - \anchor comment_b_1_1 \ref b_1_1 "1.1" In future, maybe logic_errors are also handled, so configuration errors can nicely be presented to the control system. This may be important especially since logic_errors may depend also on the configuration of external components (devices). If e.g. a device is changed (e.g. device is another control system application which has been modified), logic_errors may be thrown in the recovery phase, despite the device had been successfully initialsed previously.
@@ -212,17 +208,12 @@ Note: This section defines the internal interface on a low level. Helper functio
   - \anchor c_2_7_1 2.7.1 The error is reported to the DeviceModule via DeviceModule::reportException() (cf. \ref spec_execptionHandling_high_level_implmentation_reportException "C.4"). This automatically sets DeviceModule::deviceHasError to true. From this point on, no new transfers will be started. \ref comment_c_2_7_1 "(*)"
   - \anchor c_2_7_2 2.7.2 For read operations: the DataValidity returned by the accessor is overridden to faulty until next successful read operation (cf. \ref c_2_6_4 "2.6.4"), and the current VersionNumber of the accessor is set to DeviceModule::exceptionVersionNumber.
 
-- 2.8 In doPostRead()/doPostWrite() also boost::numeric::bad_numeric_cast exceptions are caught.
-  - 2.8.1 The exception is *not* reported to the DeviceModule (in contrast to \ref c_2_7_1 "2.7.1")
-  - 2.8.2 In doPostWrite(), the exception is just caught, but no further action is required. The transfer itself has been skipped because the original exception occured in doPreWrite(), and dataLost ist already true. (cf. \ref b_6 "B.6")
-  - 2.8.3 In doPostRead() the DataValidity returned by the accessor is overridden to faulty until the next successful read operation, and currentVersion is taken from the successful transfer.
-
-- 2.9 The constructor of the decorator
-  - 2.9.1 receives the VariableNetworkNode for the device variable, to enable it to create additional, undecorated copies of the register accessor,
-  - 2.9.2 puts the name of the register (from the VariableNetworkNode) to DeviceModule::listOfReadRegisters resp. DeviceModule::listOfWriteRegisters depending on the direction the accessor is used, and
-  - 2.9.3 creates the recovery accessor and initialises the RecoveryHelper object.
-  - 2.9.4 Note: The alias name of the device can be obtained from the VariableNetworkNode, which allows to obtain the corresponding DeviceModule via Application::deviceModuleList (change the list into a map).
-  - 2.9.5 The code instantiating the decorator (Application::createDeviceVariable()) has to make sure that the ExceptionHandlingDecorator is "inside" the MetaDataPropagatingRegisterDecorator, so the overriden DataValidity flag in case of an exception is properly propagated to the owning module/fan out (cf. \ref c_2_7_2 "2.7.2" and \ref c_2_4_6 "2.4.6").
+- 2.8 The constructor of the decorator
+  - 2.8.1 receives the VariableNetworkNode for the device variable, to enable it to create additional, undecorated copies of the register accessor,
+  - 2.8.2 puts the name of the register (from the VariableNetworkNode) to DeviceModule::listOfReadRegisters resp. DeviceModule::listOfWriteRegisters depending on the direction the accessor is used, and
+  - 2.8.3 creates the recovery accessor and initialises the RecoveryHelper object.
+  - 2.8.4 Note: The alias name of the device can be obtained from the VariableNetworkNode, which allows to obtain the corresponding DeviceModule via Application::deviceModuleList (change the list into a map).
+  - 2.8.5 The code instantiating the decorator (Application::createDeviceVariable()) has to make sure that the ExceptionHandlingDecorator is "inside" the MetaDataPropagatingRegisterDecorator, so the overriden DataValidity flag in case of an exception is properly propagated to the owning module/fan out (cf. \ref c_2_7_2 "2.7.2" and \ref c_2_4_6 "2.4.6").
 
 \subsubsection spec_execptionHandling_high_level_implmentation_decorator_comments (*) Comments