Enhance Error Contextualization for Actor Framework

[pettaa123]

The Actor Framework generates generic error messages originating from the underlying techniques it employs, even when these errors are directly related to Actor Framework usage. This lack of contextual specificity makes it challenging for developers to identify and address issues effectively within the framework.

Replace error 1448 ("Bad Type Cast") and error 1556 ("The reference is invalid") with Actor Framework-specific error codes and descriptions. These new error codes should reflect the context when it is safe to assume their origins: specifically, error 1448 indicating "Recipient is no longer running" and error 1556 indicating "Recipient does not implement the sent message type."

Consider replacing error 43 with an Actor Framework-specific error code to represent a normal stop.

[niACS]

Upgrading Errors 1448 and 1556 to framework-specific codes is reasonable, and will primarily benefit new framework users.

(1448 indicates a wrong message; 1556 indicates a bad enqueuer, which can be a stopped actor or an actor that was never launched.)

These should be handled at the point of generation, where we can guarantee the cause. We can handle 1448s in message.lvclass;do.vi. 1556s would be handled in message send VIs, which means modifying the send VI template. Developers working in legacy code would have to rescript their messages to benefit, though this would be optional. (I'd expect most legacy systems have resolved their 1556 issues.)

In both cases, care should be taken to ensure that upstream errors propagate correctly.

The 1600 block of error codes is reserved for Actor Framework, so we can assign codes in that range as we see fit. (1648 and 1656?) However, we will need to add causes to the appropriate error files, and they would need to be localized. I haven't ever played with that part of LabVIEW, so someone will need to weigh in on what would be required.

[niACS]

We've talked about changing Error 43 (the "stop" error) to something appropriate to AF off and on for the last 10 - 12 years, and the answer has always been "don't do it." The benefits are minimal, while the potential impact on existing systems is unknown but potentially quite large.

There isn't really an upside to this change. The base implementation of Handle Error.vi clears Error 43, so it doesn't get reported to the rest of the system when the actor stop, and, therefore, there is no need to explain what the code means. The only real effect is that Error 43 is also returned by the File Dialog if the user cancels (Error 43 is "operation cancelled by user"). If a developer opts to pass along the error generated by this dialog, he can inadvertently stop his actor. This is undesirable, but self-correcting. Conversely, I'm sure some other developers think this is a slick little trick, and actually rely on this behavior from time to time...

Which leads me to the down side. This has been the way AF works for 14 years, and people have come to rely on this behavior. We have trained people to have their actor methods return Error 43 as a way to stop their actors for close to 10 years now. If we change this behavior, all of those developers will have to refactor their code, or we'd have to provide tools to do it for them (which is high risk).

I suppose we could opt to support both error codes, but what's the value of that? We'd still have Error 43, but now we'd have two error codes that stop actors, and no one will ever see an error report with the new code.

We should leave this as an odd historical quirk. It doesn't hurt anything, changing it is of no actual value, and it gives students a good chuckle in the AF course.

[svelderrainruiz]

This GitHub issue contains valuable information that may be used as a starting point for multiple GitHub issues, therefore i will move this issue to be a discussion so that we can create multiple atomic GitHub issues in case @niACS and his team makes a recommendation to NI to create features based from this discussion.

[svelderrainruiz]

You may see that this issue has been closed, but that is because it has been transformed into a discussion so that we can keep our conversation there for other people to see.