Error IN and Error OUT

[labview1958]

Is error in and error out important? If I leave out error in & out can I VI still run. What is the purpose of errir in & out?

[Timothy_Wright]

With automatic error handling it may not seem that proper error handling (i.e. wiring error in/out clusters, error output at end of the program) is important. I find that the error clusters are the most useful when ensuring proper flow control of the program, for example when you want VIs that don't pass information from one to another (such as two different instruments) to execute sequentially. I use the error clusters for flow control so much that when I encounter third-party VIs that don't use the error in/out convention, I will create my own VI around it as a wrapper to include the error in/out. Sure you could use sequence structures, but the error clusters create much cleaner code. I also find the error clusters useful when creating my own VIs as a standard way of error handling.

A quick question that I'm not sure about, what happens in a National Instruments VI when an error is created but it isn't something that necessarily will crash the program? Will the automatic error handling still report it immediately, or does the programmer need to handle it herself?

[Roy_F]

To answer Tim's question about automatic error handling and NI VIs:

The VIs shipped with LabVIEW have the VI property for Automatic Error Handling turned off. We are "supposed" to write good code, which includes good error handling. So the automatic error handling dialog should never be posted from within a VI shipped with LabVIEW. If a call within one of our VIs does not have Error Out wired, it's because we know the execution of the code is correct whether an error occurs there or not (that's the idea, anyway).

The bulk of the value to automatic error handling is that it allows you to write "quick and dirty" code and easily catch your mistakes. It's most useful for prototyping and initial code development. Production code should always be reworked for good error handling if error handling was not included in the initial design and implementation.

Error handling often boils down to just helping you identify where an error is occurring and what is wrong. That's what the automatic error handling does for you. It just tells you error xxx occurred at location yyy and it allows you to break in at that location. You then figure out what is going on and add more code to your application to handle the condition (aha - error handling, not just error reporting). For example, what should I do if the file I am to write to already exists and is read-only? Should I just quit? Should I report file open error and quit? Should I report the file is read-only and prompt for a new file?

Error handling code takes time to design and time to write. If all goes well all the time (shut your eyes and dream for a moment), then most error handling code is not needed. But all does not go well all the time. The better you get at using Error In/Out, the better off you will be in the long run. Wiring Error Out forces you to consider what you will do when an error occurs at that location. It makes you think and you make a conscious decision about what to do (which can include "do nothing"), but obviously a conscious decision is better than the unconscious decision which currently happens when you don't consider errors and hence default to "do nothing".

Good code doesn't need automatic error handling turned on. There are times when it is helpful to all, e.g. prototyping, and there are times when it is always helpful, such as demos or when the developer simply doesn't want to write error handling code. Not everyone wants to write really good code. And some devious developers may want to find out who's pointing them to read-only files and not let them run their application anymore. 🙂

Roy

[LV_Pro]

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

[labview1958]

Is there a tutorial on error in & error out. I would like to go through some SIMPLE examples. Can anyone help?

[tst]

Chapter 6 of the LV manual (Help>>Search the LabVIEW Bookshelf) includes a segment about error handling.
You can look at the NI VIs to see how error handling is done or (better) look at the OpenG VIs.
In the end, error handling is different for each application (what to do if the file is missing? Alert the user? Create a new file? Stop the program? Ignore?).

[falkpl]

Is there more information on error handling other than the chapter 6 of the user manual? I would like to add more error handling (add my own error codes) and I have but I find that I don't have a great software process for incorporating error handling throughout my application designs. Does any one have more resources. I know that error handling and documentation are always the most ignored features although one of the most important to the success of a project. Any advice is appreciated.

Paul

[tbob]

Here is another important tip on error handling. If you look at some of the NI vi's, you will see a error/no-error case structure with the error in as the input. If an error in has an error condition, the entire code is skipped. This is very useful and proper for such functions as GPIB, VISA, and file operations. What if the VISA initialize failed? Any subsequent VISA calls to that session might cause a meltdown. By using the error in and the case statement, an error would cause the code to be bypassed, saving the computer from possibly crashing. The error out will display the particular error encountered. See attached example.

[labview1958]

I have LV version 7.0. Your error.vi is in version 7.1. Can you please change from 7.1 to 7.0?

[Odd_Modem]

Using error in and error out is part of the LabVIEW style. It is one of the most straight forward and simple examples of the multi-threaded nature of LabVIEW: a function (VI) that can return more than one variable, in this case the error code.

The VISA vis and the the GPIB vis more or less show the style, with the error cluster connectors in the lower left and right of the connector pane. With VISA again, it is most useful to serialize all the operations of communication with the remote processor so it becomes natural to use the dataflow of the error cluster (or the VISA reference) to implement this serialization.

In C, you have to write code like

if(!(ReadByte("eieio"))) ThrowError();

i.e. code with a bunch of if statements that check the return code of each function call.

With LabVIEW, the error cluster is an input to the next function. Generally, if an error is input, the VI will not do anything and just pass the error along, arranged so whatever deals with errors at the end of the chain gets the first error message generated (the target of the throw). In a sense, LabVIEW expresses lexically what happens dynamically when an error is thrown.

I suppose the automatic error handling feature of the 7s might be an implementation of the dynamic.