Leaderboard

Hello, For the past 2+ years, I've always thought that official LabVIEW nodes/VIs do nothing (and only output default values) if they receive an error in their "Error In" terminal. As a result, I wrote code like this: (I thought that a memory leak could occur if an error input stopped Release Queue from doing its usual job) Today, I discovered that nodes like Destroy User Event and Release Queue actually still work even if they receive an error. I guess this behaviour makes sense. However, I'm now wondering if there's a definitive guide on how errors should affect code execution -- Should I expect all nodes/VIs to do nothing if they receive an error, except for "cleanup" nodes/VIs? The reason I investigated this is because I'm writing a library that uses an initialize-work-deinitialize pattern. To be consistent with official LabVIEW nodes/VIs, it looks like my "Initialize" and "Work" VIs should do nothing if they receive an error, but my "Deinitialize" VI should still attempt to free resources even if it receives an error. Would you agree?

There's a few of us at NI -- in several different products -- that saw this trend a couple years ago when Adobe first started trying it out; we preemptively raised objections to LabVIEW moving in that direction, even though there were absolutely no plans to do so at the time. I'm glad we did... because although I can imagine NI will have some products at some point that follow this model, but I do not expect LabVIEW to go that way. Speaking as an R&D insider: I observe enough of an "allergy" within NI to LV adopting this model that it is unlikely to happen. Now, taking off my R&D hat and putting on my LV user hat: I don't like the software as service model. I get why businesses like it though. If you also don't like the software-as-only-a-service model, please mention your objections to your local Field Sales agent, as a ward against future ideas. There are a lot of advantages to *customers* to the software-as-only-service model, and Adobe was able to make the change because it got the customers who liked the portability/upgradability/no-IT-involvement-ability of the service model excited about it first and closed down a lot of the objections before they even got raised. By the time most Adobe users even heard about the change, it was fait accompli, with blog posts from users excited by the change holding top search result slots. So you might want to occasionally mention to Field Sales, "You know, I really like owning my own software." Express not just objections but also advantages with the current situation. Doing so will help keep the allergy strong!

It tells me I look 47. I blame the Actor Framework for turning my hair gray