Report Error Msg.zip

[AristosQueue (NI)]

Here's a message class for passing an error to any actor. I made it this morning (when I was still awake) at someone's request (don't recall whose). Seemed like a good idea... what are the thought's of including this message class in version 4.2? I would not put it in the .lvlib file, but distribute it with the AF, just like Batch Msg and the others. Would you make any tweaks to it? It's pretty dead simple, but I can see the utility.

[Oli_Wachno]

AQ,

could you please also provide a 2011 version?

Cheers

Oli

[AristosQueue (NI)]

Done:

https://decibel.ni.com/content/docs/DOC-23517

[onnodb]

Seems useful enough to include in the library distribution. Then again, I also find the class just a bit risky:

• You're directly inserting an error condition into another Actor's message loop.
• The way the "Do.vi" method works, means that this Message can be sent to any Actor — in contrast to 'normal' Messages, which have to be explicitly 'accepted' by an Actor (by implementing a "Do.vi" that calls a method on the Actor's class).
• There's no way to see where the error came from.

So: I guess it can be useful in some corner cases, but I don't feel like I would recommend using it without a good reason.

[AristosQueue (NI)]

> The way the "Do.vi" method works, means that this Message can be sent to any Actor

Well, any actor that you have the ability to message. Keep in mind that actor communication is limited by definition.

Your objections are similar to my own, but I have basically built this same thing a couple times -- if my nested actor has an error it doesn't know how to handle, it escalates it to its caller. The error code needs to describe the situation.

I thought about including the sender's enqueuer as part of the payload to identify the sender, but didn't actually do it that morning when I wrote the class... that would be easy enough to add.

[Todd_Lesher]

Most of the (very few) actors I've written have three types of errors:

1. Error that the actor itself handles without stopping itself or telling the caller about
2. Error that the actor itself handles without stopping itself, but messages the error to the caller
3. Error that causes the actor to shutdown, here comes Last Ack for the caller to handle

The logic for choosing between 1, 2 and 3 are in the actor's Handle Error.

I'm not sure if this is the best way for me, yet.

[AristosQueue (NI)]

ToddLesher wrote:

1. Error that the actor itself handles without stopping itself or telling the caller about

2. Error that the actor itself handles without stopping itself, but messages the error to the caller
3. Error that causes the actor to shutdown, here comes Last Ack for the caller to handle

Case #2 is what this message is meant to address. I think of this message as the easy way to pass the buck on an error up to my caller. I would have an actor send it from its own Handle Error and not return any error to its own system (though I might set a flag in the actor's private data that says "an error has been passed up to the caller... all other messages should be treated specially until we hear back from the caller about whether the system is safe to proceed or not").

[AristosQueue (NI)]

AristosQueue wrote:

I thought about including the sender's enqueuer as part of the payload to identify the sender, but didn't actually do it that morning when I wrote the class... that would be easy enough to add.

                   

Note that I would embed the enqueuer in the string section of the error code cluster, not make it a separate data member. The reason for this is that the only thing I *can* pass up to any actor, regardless of who my parent is, is an error cluster. The Handle Error in my parent could check the string for an embedded enqueuer in the "source" string.