NI TestStand Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
manu.NET

Try Catch block to handle runtime errors ...

Status: New

Hello,

 

For the moment the runtime error handling can be managed by using ...

 

  • Runtime error options
  • Ignore runtime error flags
  • Manually, for action steps, by handling actions returns

It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.

 

TRY

    Steps ...

    Steps ...

CATCH

     case 35  // Error code = 35

     end

     case default // All other error codes

     end

End

 

Doing so, could be a way to handle runtime errors, in an other way that the global configured way.

 

Manu.

Manu.net
2 Comments
Norbert_B
Proven Zealot

While i understand the request and, from time to time, would like to see it myself in TS, it is "already provided" as "~PostStepRuntimeError" where '~' could be "SequenceFaile" or "ProcessModel" (if part of the process model itself).

I had no case where error handling was not possible in that callback(s).

 

The only main advantage of your request is that the callback is a "global" level, so the switch-case could get very long. Your request would enable the developer to distribute the collection of all cases in the sequence(s) in order to keep each segment as short as possible....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
rkoenig
Member

The lack of a Try-Catch-Final structure is a major shortcoming of TestStand.

 

The PostStepRuntimeError callback works, but the "global" nature, as Norbert points out, makes for messy code and has high risk for mistakes. It demands developers and reviewers to work in multiple locations to understand sequence flow. Readability is a major reason why code reviews are difficult with TestStand.