Proposal - Improved Error Propagation in Actor Core.vi

[Darren]

Based on user feedback, I am proposing the following change to Actor Framework.lvlib:Actor.lvclass:Actor Core.vi in a future LabVIEW release:

(note that both frames of the loop's outer-most error case structure are shown)

Background

There have been rare reports of the Priority Dequeue VI in the Actor Loop returning errors. In these situations, there is a problem on the Framework side, as opposed to a problem on the Actor side. For Actor-related errors, it makes sense to run the Handle Error.vi method. For Framework-related errors, it makes sense to immediately shut down the message handling loop. With the current design (the "Before" picture above), there is no meaningful way to know in your Handle Error.vi override whether the error was generated by your Actor or by the Framework.

Solution

To better differentiate between these scenarios, I am proposing the improved error propagation in the "After" picture above, which skips executing both Receive Message.vi and Handle Error.vi on incoming error from the Priority Dequeue VI. Note that you can still operate on any error that occurred (framework-related or actor-related) in the call to the Stop.vi method. Additionally note that the loop no longer propagates an error from a previous iteration, and that the VI now drops incoming warnings (the Actor Framework, in general, does not propagate warnings).

Stephen, Allen, and I are all in agreement that this proposal is an improvement over the current error propagation in Actor Core.vi. I am posting here to get feedback from the AF community over any concerns with this proposed change.

[Dhakkan]

This is certainly a step in simplifying logic.

Warnings were always a grey area for me. Incoming Report Error messages will continue to be processed normally.

Will the Framework error values be documented?

[Darren]

---

@Dhakkan wrote:

Will the Framework error values be documented?

---

As I mentioned, errors from Priority Dequeue are extremely rare, and we don't yet have a reliable way to reproduce them. I'm only aware of one specific application where this is currently happening. And when they do happen, they appear to be generic queue errors, like Error 1 from Dequeue Element. So there's nothing specific to document at this time, really.

[CaseyM]

👍

I don't see any problem with this.

[paul.r.r]

What error is priority dequeue returning? Based on my understanding of the AF priority queue, the only way that that method could return an error is if there's an internal LabVIEW problem like a memory overflow with the queue, or someone is doing something really wonky like getting the queue/DVR reference number by flattening the actor data to read the reference number then creating a new instance of it and destroying it.. Is that not correct?

With the proposed change, the actor that stopped would only catch the error code, with no other information about why it stopped. If there is a calling actor that actor would have full access to the error, but I don't like the assumption that there will always be a caller actor, or that it is always the calling actor's job to process the errors of its nested actors. Perhaps it is adding unnecessary bloat to the framework, but I think I would like something giving notice to the bad actor that its going down due to a framework error. A handle framework error method in the error case, or maybe even just a specific error code to signify an actor framework error?

[r_good]

I am all for this idea.  I really like removing the error shift register.

[Darren]

FYI this change is present in LabVIEW 2024 Q3, which is now available for download in NI Package Manager.