6.4 Error Handling

   

---

Decent error handling is one of the most challenging aspects of software design and, coincidentally, one of the most ignored.

When thinking about error handling there are two phases of a project that need considering: the development phase and the released phase. Each phase has separate error handling requirements. In development you want your application to bleat loudly and generally get itself noticed the moment an error occurs. You can then fault-find and fix it. When your software is released you will have to deal with errors more elegantly. For example, it will be important to have a log of the errors.

Another thing is propagation and handling of errors. LabVIEW provides the error cluster that links VIs together; any errors upstream are handled by the next VI in the sequence. There are questions of coupling with this approach, for example, does the next VI need or want to know about errors in its predecessor?

Consider a system designed using the standard data flow method as shown in Figure 6.48.

Figure 6.48. Pass through error handling.

If an error enters VI number 2 it will pass through without completing its function ”this will be repeated for VI numbers 3 to 6. LabVIEW is a parallel processing, multithreaded language. So the simple data flow model seldom holds true. So, for example, if you have multiple While Loops processing in parallel and a reasonably large program, the above method of error handling can lead to unpredictable results.

Because of loose coupling, components have a tendency to be more self-contained than the standard data flow way of writing software. This should be reflected in the method of error handling. Components should be able to handle their own errors as much as possible. Why not have an Error Control Component that can either throw up a dialog or log the error to a file? This component can be placed inside another component or at the end of a sequence, allowing complete flexibility.

There are also areas of your code that are more likely to fail than others. These high-risk areas are usually when your code interfaces with the real world, and if you concentrate your error trapping, in these areas you'll catch a large percent of your nasties.

Areas to look at carefully include:

• Database interaction

• File interaction

• Hardware interaction ( especially when controlling hardware)

• Printing

• User input

Lastly, there is severity of error. Is your error an exception or a warning? Is it fatal or just aggravating? Is the closing down of the application an appropriate response to the reported error?

If you have designed your executive as a state machine with each state mapped to a state of the system, why not add error states as well? Are they not valid states for the system to be in?

The following example is an empty test executive that has five test states, an initialize, a reset, and various error states. The order of operation is controlled by the array of Strict Type Def enumerated types. In this example, all the subVIs do is throw an error if the input is set to <Moan>, which can be set from the Local area of the Front Panel. The Front Panel is shown in Figure 6.49.

Figure 6.49. Error States Front Panel.

To change the order of the states, update the array of enumerated types, and to force a failure, set the associated enumerated type to <Moan>, which will activate the required error state. The code is shown in Figure 6.50.

Figure 6.50. Error State diagram.

The array of enumerated types is input into the For Loop where it is auto-indexed. The single selected enumerated type is then input into the While Loop shift register and a case is selected. If the case is okay, the "finish" case is called and the next enumerated type in the array is selected. If an error condition is called that case is executed as well.

This structure allows the modeling of a systems failure condition to be executed as well as its normal running condition. It also allows errors to be categorized and organized accordingly (warnings, exceptions, and fatal errors). A brief look at the rest of it is shown in Figure 6.51.

Figure 6.51. Error State cases.

---

Top