Handle Error.vi

[Ben_Phillips]

I've become confused about error handling in AF, specifically one part of 'Handle Error' and what you should do when you override it.

So probably we can agree that if you have an actor that may receive errors during normal operation (things like HW I/O or network comm), and you don't want it to simply shut down, then you are going to need to override Handle Error.

What I find strange is that you cannot really call the parent method in your override, since it will always output 'stop actor?' as true.  i.e., even if you override the function, clear the error and feed that into the parent method, your actor is still going to stop.

But if I just override the method without calling parent method, then I need to copy the parent method's code for handling that error 43.  And it would be copied like that over and over, for every place where I need to override Handle Error.

It seems like the ancestor Handle Error should not stop the actor when it receives no error in.  That way I could clear the error after handling it if it's not error 43, and then still be able to call the parent method, avoiding copying boilerplate code.

Maybe I just answered my own question by writing it out that way.  After all, even if it were changed like the above paragragh, I would still have boilerplate code in every override:  I would still have to watch/filter for error 43 every instance, and pass it along.

[AristosQueue (NI) · Accepted solution]

Put the Call Parent *inside* your case structure. In other words, have a case structure to check for your error code. In the case where the code matches, do not call the parent. Only do the call parent in the default case.

[Ben_Phillips]

Hmmm, so obvious in hindsight.  Thanks...

I do, however, reserve my right to ask further CLAD level questions here! 

[AristosQueue (NI)]

Ben_Phillips wrote:

I do, however, reserve my right to ask further CLAD level questions here! 

Not a problem. Just steer clear of my all time favorite, "If I don't use global variables, how am I supposed to pass information between the frames of my stacked sequence structure?" I had a hard time not being snarky on that one.

[KuGr]

I know this question has been answered, but it seems like a good place to ask one more thing about Handle Error.vi...

Is there a technical reason why the Handle Error.vi has Reentrancy set to Non-reentrant execution?

Ideally it is rarely called so it is not that big of a concern, but it could bottleneck a failing actor network.  On the positive side, it makes it a great debugging break point.

[AristosQueue (NI)]

It's mostly that I have been advised to only make things reentrant when they need to be reentrant, not just because things happen to run in parallel. Getting a clone VI from the clone pool can be expensive compared to just waiting a few moments for the parallel code to be finished. And debugging is easier, as you noted. Since it is generally rarely called during the lifetime of an actor, I didn't make it reentrant. Does it need to be?

[KuGr]

For the reasons noted, I don't think it needs to be.  I was just surprised that it was not, but I understand why now.

Thanks!

[PrimaryKey]

Don't feel bad. I scratched my head about that for an hour or so before coming up with case struct