Aspects of error handling

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in Figure 8.

Figure 8: producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the General Error Handler.vi shown in Figure 3 to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the Error Code Database.vi (see Figure 9) for specified error codes in LabVIEW. Figure 9: connector for the Error Code Database.vi This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the General Error Handler.vi. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the Event Viewer (right-click on My Computer and select Manage from the popup menu) shown in Figure 10 and Figure 11. The eventcreate command can be used in Windows to log events to this application. A VI log event error for logging errors to the Event Viewer is available.

This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE: The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended 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.

Figure 10: Event Viewer in Windows

Figure 11:Event Properties in Windows