@DonBorste wrote:
[...]When I don't deliver the VI error path to "Step.Result.Error" it works!
[...]
Heiko,
this "workaround" can bite you some time in the future...and that could hurt.
So you should think about "what does that error mean for the system".
If the error is something internal to the code module, the code module has to correct it.
If the error is on system level, you must not drop it! Dropping it could lead to invalid tested UUTs, which, in worst case, test faulty ones as "Passed".
What you have to do is to implement a proper PostStepRuntimeError callback which revokes the error for specific situations, handle it (e.g. by logging) in others. In specific cases, the callback can shutdown the complete system to prevent hardware failures in the test system.
So depending on the "severity", you have to react.
I wanted to point out that proper error handling is
a) mandatory
b) most often not simple
Of course, you are correct that an automated test system must not call blocking dialogs.... but simply not handling (aka "ignoring") errors isnt a solution either...
Norbert
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.