The existing error system is as refined as we can make it given the backward compatibility that must be maintained. The problem has been investigated multiple times and we believe the current solution is the best of all possible bad solutions.
"Error 7 occurred at Create Cursor From File.vi
Possible reason(s):
LabVIEW: File not found.
....
NI-488: Nonexistent GPIB interface"
For this error, "File not found" is sensible. "Nonexistent GPIB interface" is not.
I must add that with alot of inlining going on now it's of utmost importance to have thorough error descriptions as you can no longer rely on your call chain to include the offending subVI (if it's inlined into the caller).
My toolset uses <err> when adding a description for an error code without prior descriptions defined, but <append> when it adds a description to an error code with pre-existing description(s). "Pre-existing descriptions" cover both the built-in ones, user defined by XML-file, as well as dynamically defined at runtime using this toolset.
The rationale is that I don't want to override existing error descriptions.
I could add an option in the toolset to always replace any pre-existing descriptions, either as a second version of the SetError/SetWarning/SetDescription functions or as an optional input. Do you see any use cases where you'd want to ditch the pre-existing description? Wouldn't you in that case just select an error code in the user-range instead of using a built-in error code? Also, setting several different descriptions for the same error code in the user-range is possibly dynamically with this toolset, namely to allow for several apps to set their own error descriptions in overlapping error code ranges without overwriting each other's descriptions.
I could post examples if you'd like, but maybe this thread isn't the proper forum for this?
kewal: Believe it or not, no, LabVIEW cannot generally do this. There's no contextual information for LabVIEW to generally know. There are 97 error codes in all of NI that still overlap... the GPIB errors with the original 97 LabVIEW errors, and to do what you're suggesting would require an oracular database of all nodes that can return error code 7 and why that is being returned.
LabVIEW is dependent upon the various generators of errors to provide the information. You can see the discussion about <err> vs <append> from Steen. Because the general error 7 is ambiguous (either LV or GPIB), the general text for error 7 has to mention both. With the <err> tag, the code that generates the error can override the general text. The problem is that we use the error codes specifically to avoid bundling description text into the error cluster -- such text is problematic on several platforms and it creates problems for localization (i.e. the error is generated on a French machine but translated for humans on a Chinese machine -- if the text gets embedded at generation, then the error description is locked to French).
This is a historical problem of LabVIEW, one that we are addressing with LabVIEW NXG... GPIB will be a separate download for those users who want to use it, and will install its errors separately, so no one will see overlapping descriptions unless they have deliberately installed GPIB, which is a smaller and smaller percentage of our user base as the years go by.
