I agree with both the previous posts. Error handling tends to cause us to look at the code and see what is important and how a section of code not responding as desired will effect the rest of the program. Regardless of how well we try to write our code there will be instances that aren't what we wanted; operators entering invalid data, DAQ data that is way outside expected (hardware failures), files that are supposed to be there that have been deleted. By putting error handling in early it causes you to begin to think about these issues. Error in/ error out also allow us to determine the flow of our programs. I frequently put it into even very simple vi's that have no actual error handling, just wiring error in to error out. One example was enclosing a native LabVIEW "Wait" component in a sub-vi, with error in and out allowing me to place the timer on the block diagram between two other vi's, forcing the delay to occur between them, rather than when ever LabVIEW decided the wait would occur. And a really interesting use that a very talented programmer(Mike Porter) showed me, was to use custom error codes to allow conditional execution of downstream vi's by monitoring the error cluster wire for specific numeric "error codes" and reacting to them conditionally. It allowed "passing messages" down the execution stream without adding any wires.
My vi templates that I create always have the error in and out predefined (as well as a vi documentation template!)
Good luck on your wiring
P.M
PutnamCertified LabVIEW Developer
Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5
LabVIEW Champion