Replies: 2 comments
-
|
I am turning this into a discussion for now |
Beta Was this translation helpful? Give feedback.
-
|
The two most common error messages we want to convert are 1448 and 15556. A 1448 generated in a Receive Message.vi means the message went to the wrong actor type. A 1556 generated in an Enqueue.vi means the enqueuer is bad (actor missing or dead). Both can be easily promoted to a 1600 series message. I'd vote for 1648 and 1656, for symmetry. This is the most objectively correct solution, in my opinion. The big down check, as Casey mentioned, is that someone, somewhere, may be relying on detecting and responding to those specific errors in context. We'd be shivving that guy, which is something we'd like to avoid. Alternately, we can add explanatory text to the error text files, so the user gets the original error code, but with more helpful explanations. Someone with more experience working with those files should comment on the feasibility of that approach. I don't know, for example, if we can provide a small additional error file, or if we'd need to modify a file that ships with LabVIEW. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is your feature request related to a problem? Please describe.
Errors that arise from some actor framework actions are very generic (e.g. to more specific class). Could we have more verbose errors that point to the issue more easily (like they have for DQMH).
Describe the solution you'd like
Thinking that changing error codes might be problematic for existing applications, then at least more descriptive errors for existing errors generated in the Actor Framework core VIs.
Describe alternatives you've considered
Different range of error codes for AF.
Additional context
N/A
Beta Was this translation helpful? Give feedback.
All reactions