AF error reporting and handling

[CaseyLamers1]

That is a good idea. I didn't have any tracking implemented by the logger itself. I do have tracking in one of my 3 systems that keeps track of all the launched things that I want to send a last ack prior to stopping the logger.

[Jeannius]

I was suggesting that the architect be able to modify the Error class to define their own errors. I understand what you are suggesting, but not what I had in mind (maybe what I had in mind has lots of Computer Architecture flaws!).

Basically the architect of the project would override the error class to add his owns errors "error 1 means ...". When an error occur the singleton knows what it means because it was predefined and it also knows what actor it came from. The ultimate vision is to always alert the user of a new or predefined error, with the predefined errors giving you the option of shutting down or not (or even advanced option as to fire up  a certain vi). Undefined/new errors may shut down but will at least advise the user where the error came from (even in the form of a dialog so you don't have to go create break points and chase down where errors occured and stuff). For me in particular, the error cluster can be hard to decipher at times.

With those parameters, I believe the singleton is the way to go, but then again I am not an expert.

[AristosQueue (NI)]

Jeannius: Separate your thoughts on the error message class from the error handler actor class. You've got two separate ideas there and both are worth thinking about, but one does not necessitate the other.

The error mesage class is a message that one actor is capable of sending to another actor. Creating child classes of this that are specific to a particular error is in many ways a good idea. Indeed, from any given nested actor to its caller, creating *any* message, error or otherwise, that is the specific information that the nested actor wants to report is a good idea.

But you don't need (or necessarily want) a central error handler for those error messages. Whoever receives those error messages responds based on the information packaged into the error message. The less you can create a central actor that has to have omnicient knowledge of the whole system, the easier it will be to add and remove code from your system.

A deep level actor (more than 1 level away from your root actor) should almost definitely NOT be asking ANYTHING of the user. Sending errors from deep in your architecture directly to the user generally doesn't have enough context because the deep actor doesn't have enough context. Consider a copy of a directory. The Directory Copy Actor spins up, and it spins up N File Copy Actors. One of the File Copy Actors has a problem. Do you want to ask the user "copying the file failed -- abort copying the file?" Or would you rather say "copying the file failed -- abort copying the directory or continue copying without that file?" The deep actor doesn't even know that it is part of a larger copy operation.

[Jeannius]

Thank you for clarifying this for me. You are absolutely correct, more thoughts need to go into this. Error message and error handler are separate and should have their own discussion.

I still believe in both but doing them in a low couple/zero couple way may be a daunting (if not impossible task).

[Jeannius]

So if I understand this correctly, "Handle error" already does one of those jobs (which one, I don;t know enough to say).

The issue is, it only does this job after the actor is in "full on" mode, not during pre-init, not before "actor core" calls the parent method.

[AristosQueue (NI)]

Jeannius wrote:

The issue is, it only does this job after the actor is in "full on" mode, not during pre-init, not before "actor core" calls the parent method.

This is correct. That's because generally the handling needed for an error during the initial part of Actor Core is different from an error once messages start arriving -- if the actor never even gets up off the ground, there's generally nothing to be done except to close back down and let the *caller* ask the user what to do.

If that's not true in your case, here are your options:

a) Do your work in Actor Core.vi and then use the Send Report Error Msg.vi to send an error to yourself to handle.

b) In Pre-Launch Init.vi, send yourself a High Priority message called "Initialize Msg" and do the work that you were doing in Actor Core.vi instead inside the Initialize.vi.