8.5.2.1. Dealing with failure
From time to time, there might be problem when running a code. The source of these problems might differ from one instance to another. In the Relauncher module one can consider different case:
the command is returning a failure code. A convention for a command is to return 0 if all went well which means that what should be done has been done while any other returned value can be considered as a way to inform that a problem has been met. From the Uranie point of view, there is no way to know what kind of error is meant as it is command dependent.
the
systemfunction is returning other values. The command provided by the user is passed to thesystemC++ function and on top of the non-zero returning value (discussed above), there are few specific cases. Among these, one can find the case where the command is not known (the user made a mistake in theTCodeEvaldefinition) or the command is suffering from an internal problem preventing from even reaching the exit (a segmentation fault for instance). With most Linux platforms, the former returned code is 127 while the latter is 139. This interpretation is just given for illustration purpose but unfornutatly no generalisation can be done.no output file is created. In this case, nothing can be done, all output variables will be missing and this might arise even if the code is not returning any specific failing code (see the discussion above).
One or more output variables are missing in the output file. This is special, as it can arise if the command has stopped during the writting process, but this also can be coming from an empty vector whose output formatting has not properly being taken care of. This is discussed in Various file format and illustrated in a use-case macro Macro “relauncherCodeMultiTypeKeyEmptyVectorsAsFailure.py” because of the way the output Key-format output file is written
All these problems will be considered as a failure from the command. As such, the input configuration will be discarded and not stored in the final dataserver object. The following paragraph discussed the way to get back all failed configurations.
Unlike in Dealing with attributes where all the methods are inherited from the
TMaster class, the method setSaveError(TDataServer *tdserror) has been implemented in order to
help handling the command failures discussed previously. Its only argument is a pointer to a
dataserver object in which all failing configurations will be stored. Example of its usage is shown
in two use-case macros with the classical flowrate case in Various file format
and illustrated in a use-case macro Macro “relauncherCodeFlowrateSequentialFailure.py” and when an
empty vector is interpreted as a missing information because of the wrong output file formatting,
see Macro “relauncherCodeMultiTypeKeyEmptyVectorsAsFailure.py”.