Possible Errors Returned by vi.lib

[GeorgeG]

I am looking for a list of errors that could be returned by the things in vi.lib. I've tried searching, but the search terms are pretty generic and I get lots of links to the list of ALL error codes. But I want to know the (exhaustive?) list of errors that could be returned by each VI (like Enqueue Element, or Release Notifier, or Property Node). Does such a thing exist? It seems hard to do really good error handling without it... And hard to know what kinds of things will give the code trouble.

[Rolf Kalbermatter]

I am looking for a list of errors that could be returned by the things in vi.lib. I've tried searching, but the search terms are pretty generic and I get lots of links to the list of ALL error codes. But I want to know the (exhaustive?) list of errors that could be returned by each VI (like Enqueue Element, or Release Notifier, or Property Node). Does such a thing exist? It seems hard to do really good error handling without it... And hard to know what kinds of things will give the code trouble.

This thing doesn't exist and would be more or less impossible to compile as there are potentially many differences between LabVIEW versions. Basically error handling is best done on the principle, that if there is an error and it is not a very specific error you know about to be a legitimate error result in this particular situation (e.g. timeout when communicating with an instrument or over network) you should always assume a real error and bail out in one way or the other. Code that does extensive if (error == xx) else if (error == yy) is always going to be a pain when upgrading to a newer LabVIEW version (or just installing a new IO driver too) since these error codes can sometimes change (when for instance more descriptive error codes are introduced).

That is my principle anyhow, maybe there are others, but I would consider them to be unmaintainable over a longer time. My code often does suppress timeout errors in the error cluster and detects the timeout case and then simply goes back into waiting for the next message. Also when you do network communication, you have besides timeout also other errors such as connection closed by peer, or similar, that are real errors in term of the communication link, but most likely should be handled explicitly by your protocol handler by closing the connection and reconnecting to the peer, without causing any error report to the higher hierarchy of your application. But in general unless you know a specific error should be handled in a certain way, you should treat any error as a simple indication to bail out and prompt the user or log the error or something.

[Tim_S]

The closest you're going to get to an all-inclusive, exhaustive list is from the error code files on your computer: http://digital.ni.com/public.nsf/allkb/6077DBEDA4F9FEE3862571F600449501

and the manual: http://zone.ni.com/reference/en-XX/help/371361B-01/lverror/error_code_ranges/

For practical purposes, I'd follow rolfk's advice.