Jump to content

Possible Errors Returned by vi.lib


GeorgeG

Recommended Posts

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.