General Error Handling Question

[Uriel_Ventris]

So far I have been able to catch errors if i wire standard VI's in sequence (such as file I/O), and handle errors this way.

Can I actually monitor my code for errors without such wiring?

For example, write to spreadsheet vi does not have an error out. If I leave file path empty, i get an error, yet no means of catching it. If my subVI's generate errors and have error out ports, I'm fine. If they dont, I have no means of catching the error. Is that correct?

Is there a magical way of creating an error cluster with a TRUE value whenever any error occurs anywhere (main or subVI), or is this wishful thinking?

Thanks!

[altenbach · Accepted solution]

If you want error handling in file IO, you can make you own using lower level file tools. They all have error handling.

You can open the spreadsheet VIs and inspect the code if you want. Then make changes and save them under a new name.

Also remember that there is automatic error handling (enabled by default), so the spreadsheet VIs will trigger an error popup (most often undesired!) if one occurs inside.

Many functions don't have errors (e.g. most basic numeric operations) and many errors are irrelevant. You should only try to catch the errors that really matter. Remember that lining everything up along one long error wire will force sequential operations, and thus will potentially prevent compiler optimization and parallel execution on multicore systems. One of the great powers of LabVIEW is the ease of parallel, simultaneous operation, so don't throw too much sand into its gears. 🙂

And, to answer your question, there is no magical way to add error terminals to function that don't have them. You can however encapsulate them into your own subVIs where you do sanity check on the inputs and outputs going in/out of the errorless function. (e.g. check for "not a path" output for "write to spreadsheet file", empty array coming out of "read from spreadsheet file", and/or place a explicit "file dialog" before them and catch the cancelled flag, etc.)

[Uriel_Ventris]

Thanks for a great explanation!

[Mike_Powers]

I disagree.  This block should have error handling built in.  LabVIEW is sold as an engineering solution where you can drag and drop premade blocks.  This is not a simple addition block, this is a VI which clearly can generate errors, why were the error ports left out?  It should not be left to each user to generate.

Edit:  I looked at the code under the block and found that the "General Error Handler" is explicitly added to the block diagram.  I feel this is sloppy as every other standard block leaves it up to the user on how to handle errors yet this one is hard coded into the core.

[Taylor.Kendall]

I would agree, I keep a set of polymorphic vi's with proper error handing built(check that file exsists and formatting) in that I use instead of the the NI provided ones.  They dont take long to make but will save you headaches down the line. 

[Vaibhav]

Today I stumbled upon the same situation with the Spreadsheet VIs. I deliberately kept my .xls file open while trying to write into it. Unlike the .txt files (using "Write to Text File.vi" which would overwrite the open file without any problem or throwing error), the "Write to Spreadsheet File.vi" which has no error outputs would throw an error that I cannot handle.

I even checked in the help if this is an "evil" express VI. But as I didn't read those alarm words, I didn't dig further. By some strange coincidence, this time I didn't open this VI.

But before posting a question, I came upon your post, and when you said "You can open the spreadsheet VIs and inspect the code if you want.", aah, a revelation.

Why didn't I go one step further even if I didn't read a mention of express VI? But nevermind, I learned a good lesson. Will remind me to open a VI always in case of doubt.

Still looking for a way to close a file which is open in memory (not just within labview program).

Thanks and Kudo to altenbach!