Root Actor Error Handling?

[CaseyM]

@cbutcher and I were looking at the way one particular error is (or more specifically, isn't) dealt with in AF and were wondering what others think.

Consider what happens if a Root Actor generates an error in an Actor Core override before it invokes the Call Parent Class Method:

Stop (and Stop Core) will be called, but Handle Error will not. Stop Core also only receives the error code, but not the error source information. Furthermore, Send Last Ack does nothing in the Root Actor's case since it has no caller.

What's the best way to handle and display/log such an error?

Side note: It seems like Uninit could have included an Error In terminal (but no Error Out) to deal with such a scenario, but that ship has probably already sailed.

[OneOfTheDans]

When I care about this, I do all my shutdown and error handling at the end of Actor Core.

[Dhakkan · Accepted solution]

I used to want the Actor Core to be a template, so that the template would have a 'pre-core', 'post-core' and 'helper'; with the idea of not needing to Call Parent Method. Now, I kind-of see a benefit to keeping the framework as lean as possible.

With specific regard to the scenario brought up for the current implementation of AF, the error could be handled through a Report Error to Self. No error is fed to the Call Parent Method. That way, the root's Handle Error can decide what to do next: re-try, take an alternative course of action, alert user and terminate, etc. This would be one of the first messages created, unless the root's Pre-Launch Init or the code prior to Call Parent Method has enqueued messages to caller. (Is the latter even possible?)

[CaseyM]

---

@OneOfTheDans wrote:

When I care about this, I do all my shutdown and error handling at the end of Actor Core.

---

You mean something like another subVI on the BD after the CPM?

[OneOfTheDans · Accepted solution]

Yes, but usually not even a subVI. If my Root Actor fails before starting, it's fatal (the way my apps are structured), so I'll just drop a quick message in the Log, DB, or General Error Handler for a popup.

[CaseyM]

---

@Dhakkan wrote:

With specific regard to the scenario brought up for the current implementation of AF, the error could be handled through a Report Error to Self. No error is fed to the Call Parent Method. That way, the root's Handle Error can decide what to do next: re-try, take an alternative course of action, alert user and terminate, etc. This would be one of the first messages created, unless the root's Pre-Launch Init or the code prior to Call Parent Method has enqueued messages to caller. (Is the latter even possible?)

---

I think either is possible, but I still like this idea. No need to create another error handling mechanism, just a way to get the error in the message handling loop where you can then decide how to deal with it.