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.
The problem is that there are two potential errors that have the error code 7. A lot of GPIB errors share the same numbers as LabVIEW errors. Of course the GPIB error is not not sensible if you are not using GPIB. LabVIEW gives you both possible errors for that number. As a programmer, you should be able to easily figure out which description makes sense and which description does not apply.
As RavensFan points out it can make sense that several descriptions apply to the same error code. It shouldn't be hard to decipher which apply in the specific case. And in that vein I must bring this toolset up again. It also lets you completely replace the error description for a built-in error code if you wish.
"As a programmer, you should be able to easily figure out which description makes sense and which description does not apply."
True, but remember that LabVIEW is heavily marketed at non-programmers.
Despite being a programmer, I was very confused when I first saw this message, and thought that I had encountered multiple issues (file + hardware). My colleague then told me, "Don't pay attention to that message -- LabVIEW seems to think that everything is GPIB".
The question is: Why are error codes shared between conceptually unrelated errors? (I'm guessing that it's a historical reason, where other interfaces got added on top of GPIB, but new error codes were not added)
@steen Thank you for bringing up that toolset; I can see good uses for it when I implement custom errors. I'm not sure that locally changing an official error message is wise though.
> Why are error codes shared between conceptually unrelated errors?
History. These two products had overlapping ranges before anyone realized it was a problem. In fact, all products tended to use the small positive integers as error codes.
The error code database was established in 2000 by yours truly. Since then, all NI products have had a separate range of codes for errors so they are all unique. We have pretty much deprecated out all products that had overlapping ranges except for two: GPIB and LabVIEW. These two products still have about 50 error codes that overlap. Those two products aren't going anywhere, and it is impossible to change an error code -- too many applications check for particular error codes, so once established, always established. So, the error message says X or Y.
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.
@JKSH: No, I wouldn't want to completely override a built-in error code. But I often append a description to an existing error code - for instance error code 1 which means invalid input parameter. There are many cases were an error is due to an invalid input parameter. In the GPower Array toolset the ReorderArray function can output error code 1 with an additional description for instance:
