Best Pracaces- Cleanup after error in Pre Launch Init

[AristosQueue (NI)]

Sorry. Yes. I forgot to specify that. I was in a hurry. If I have an ancestor doing that, I generally have a dyn disp method for Cleanup that I can call.

[t.kendall]

---

@drjdpowell wrote:

AQ, haven't you missed cleaning up the ancestors' references (when those ancestors didn't throw the error)?

---

This 🖕 is my primary concern. 

Also maybe the thread should have been named "How to deal with a legacy codebase where resources are allocated inconsistently in Pre Launch Init"

[drjdpowell]

---

@AristosQueue (NI) wrote:

Sorry. Yes. I forgot to specify that. I was in a hurry. 

---

It's an easy mistake to make.   That's my point.  If there were a matching Clean-up method to the PLI creation method, one that is always called, then such mistakes could not happen.

[AristosQueue (NI)]

That's a good point. No one has suggested that before. I think it can be added without breaking backward on anything since ancestor class would be a no-op.

[cbutcher]

---

@AristosQueue (NI) wrote:

That's a good point. No one has suggested that before. I think it can be added without breaking backward on anything since ancestor class would be a no-op.

---

Is the suggestion for a dynamic dispatch "On Error in PLI.vi" VI, or for a more generic "Actor Dispose.vi" that is run after an Actor Actor Core stops or doesn't run, (allowing for the case that PLI fails)?

If the latter (which initially looks more tempting, and I think was what JDP referenced with "Post Calling of Actor Core"), I can imagine current code using this in future would want to move things out of current Stop Core implementations (and error cases in PLI), is that the idea?

[t.kendall]

---

@drjdpowell wrote:

---

@AristosQueue (NI) wrote:

Sorry. Yes. I forgot to specify that. I was in a hurry. 

---

It's an easy mistake to make.   That's my point.  If there were a matching Clean-up method to the PLI creation method, one that is always called, then such mistakes could not happen.

---

Yeah I like this as a solution and it was kind of what I was looking at in the first scheenshot with the red box in Actor.vi, it maintains backcompat but give a nice new feature.

[AristosQueue (NI)]

---

@t.kendall wrote:

---

---

Yeah I like this as a solution and it was kind of what I was looking at in the first scheenshot with the red box in Actor.vi, it maintains backcompat but give a nice new feature.

---

In this, my final week as a developer for LV R&D, I pushed "Actor.lvclass:Uninit.vi" into LabVIEW 2022.

Thank you for the suggestion. I suspect this will be my final contribution to the Actor Framework.

I'll make a broader post about the AF going forward sometime before I leave.

[BertMcMahan]

Very cool, maybe now I have a reason to upgrade to 2022 🙂

(Unrelated to this post, but gotta say, thanks for developing this framework. I'm sure there are others out there that would've worked for me, but I've been using it heavily and it's made my life much easier. Hopefully whoever carries the torch going forward will be as big a fan of it as you are. Are you leaving NI completely or just leaving R&D?)

[AristosQueue (NI)]

---

@BertMcMahan wrote:

Are you leaving NI completely or just leaving R&D?

---

Leaving NI entirely:

https://lavag.org/topic/22551-leaving-ni-for-real-this-time-for-spacex/#comment-140403

[BertMcMahan]

Oh dang, sounds like a fun new gig! Good luck 🙂