Aspects of error handling
Error Handling refers to the anticipation, response, and recovery from error conditions. Writing VIs and SubVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting (debugging), modularity, and user friendliness.
The Error Cluster
The error cluster is a predefined LabVIEW cluster that is used to contain error status information. The cluster contains the following three components:
| Name | Data Type | Description |
|---|---|---|
| Status | Boolean | Indicates if an error has occurred (TRUE = error, FALSE = no error). |
| Code | 32-Bit signed integer | A standardized error code specific to the particular error. LabVIEW has a table of default error codes, although the user is able to define custom error codes. See below for more information. |
| Source | String | Textual information often describing the error and the VI it occurred within. |
Error Generation
Error Generation is the creation of an error value at the point that something goes wrong in your LabVIEW code. Error can only be generated in two ways:
- Output from a Built-in Node
- G code that creates an error value (i.e. an Error Ring, or using Error Cluster from Error Code.vi)
Output from a built-in node will result in a Default Error Code. Output from an Error Ring or the Error Cluster from Error Code.vi can result in a Default Error Code or a Custom Error Code.
Alternatively, an error can be generated by bundling the Status boolean, Code numeric, and Source string together in an error cluster. However, by doing it this way, it will not automatically include the call chain or, for default error codes, the standard error message text for the code. Therefore, it is not recommended unless it is done in Real Time or FPGA.
Error Propagation
Error Propagation is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a SubVI, it is considered good practice to place error cluster inputs and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.
The number one rule of error propagation is Don't Break the Error Chain! An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes debugging difficult.
An error chain can be broken in three ways:
- Neglecting to wire an output that is part of the error chain
- Zero-iteration For Loops
- Sloppy Merge Errors ordering
To attempt to avoid breaking the error chain, the following VI Analyzer test can be run:
- Error Cluster Wired - Detects subVIs and functions with unwired error outputs
- Unused Code - Detects unwired output tunnels of structures
- For Loop Error Handling - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
Also, the developer could choose to enable Automatic Error Handling. However, automatic error handling assumes all error conditions are tested during development and requires special tooling (VI Scripting) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used.
Error Response
Error Response is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. The ways errors could be responded to include:
- Ignoring certain errors
- Retrying the operation
- Translating or Modifying an error
- Failing the operation and closing the program
See Darren Nattinger's poster on Error Responses.
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node. However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.
Error Display
Error Display is the act of displaying error information to the end user and/or code developer. This is almost always accomplished with Simple Error Handler.vi or General Error Handler.vi.
The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling Error Code Database.vi. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The source string itself may include information to override or extend the database, and the text in either the source string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the source string is a technique that will become more common in the future.
You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
Error Logging
Error Logging involves taking errors generated by LabVIEW code and logging them to file for later analysis.