Phillip Brooks Posted April 5, 2022 Report Share Posted April 5, 2022 I am writing a wrapper to a Python class. The class has several states and will raise an exception when a method is called that is incompatible with the current state. Are there any best practices for passing exceptions back to LabVIEW? I was thinking of using the LabVIEW error cluster as a return type. Link to comment
bbean Posted April 6, 2022 Report Share Posted April 6, 2022 On 4/5/2022 at 8:56 AM, Phillip Brooks said: I am writing a wrapper to a Python class. The class has several states and will raise an exception when a method is called that is incompatible with the current state. Are there any best practices for passing exceptions back to LabVIEW? I was thinking of using the LabVIEW error cluster as a return type. That seems reasonable. I have a wrapper class and pass back a pass/fail numeric and a status string, but now thinking back it might have been more appropriate to just pass back a standard labview error cluster. In my case, the python wrapper can be run from either LabVIEW or directly in python. The thing i struggle with is passing back real-time status that normally is provided in the terminal via python print statements when python scripts run stand-alone. I'm testing an approach that just sends these via a UDP session but I haven't found a way to override the Python print command so that it prints to both the terminal (python scripts) and to the UDP session (LabVIEW VIs). Link to comment
Stagg54 Posted April 6, 2022 Report Share Posted April 6, 2022 55 minutes ago, bbean said: I haven't found a way to override the Python print command so that it prints to both the terminal (python scripts) and to the UDP session (LabVIEW VIs). I'm no Python guru, but maybe a decorator? and or maybe monkeypatching? or some combination? Link to comment
Phillip Brooks Posted April 6, 2022 Author Report Share Posted April 6, 2022 The creator of the class had provided an example code module that included functions with a return value tuple of (bool, str) representing function call success and optional string. I was conflating this return value in the example with an error. We modified the wrapper code module functions to raise an exception. I learned that the LabVIEW Python Node 'error out' connector handles a Python raise exception by returning an error with a code of 1671 and source string that contains the exception message ( is this documented somewhere? ) This is very nice! Now if we call a function where the Python object is in the wrong state, we get a LabVIEW error 1671 and the class exception string within the error out source (.e.g. "Failure to add measurement; test_run_state = [IDLE]"). Link to comment
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now