This is Part 2 of 2 of our Error Handling mini-series. You can download a PDF of both (extended) posts here in our Error Handling Handbook.
In Part 1 of this mini-series, you learned about the main components of error handling and the different levels of it. This post focuses on explaining the characteristics of quality error handling systems, and what you need to know about each one.
There are several attributes programmers and developers can look for in an error handling system and in their coding to ensure they are adequately reporting, recovering, and resolving all errors, no matter their severity.
1) Usable and used in every loop
An important part of understanding errors is knowing where they occurred. A good error handler has the logic to incorporate the loop name into the error message that encountered the error. Because creating multiple error handlers is time-consuming and difficult to maintain, there should be one main resolver VI in the error-handler module, and it should be able to be used in every loop.
2) Clear, concise, and meaningful error messages
Providing only cryptic numbers that have to be cross-referenced to a manual is not useful to an operator. Messages should give specific, usable details about the error. They should reveal what caused the error, where it occurred, and what the software is doing about it. If there are actions for the operator to take, as in the case of recovery code, the actions should be presented to the operator in a way that’s clear and easy to understand.
3) Does not block resolving the error condition
The reporting of errors to the operator should not pause or interrupt recovery actions. For example, a One Button Dialog should not block the operation while the message is acknowledged. A good error handler allows shutdown or suspend actions to occur while informing.
4) Ignores recurrent errors while resolving
In some cases, errors that caused the system to suspend may recur during the suspend states. For example, in a system in which there is a serially controlled stopper motor driver, one of the driver functions may be a “motor stop.” The error-resolving method is to flush the queue, then enqueue a set of suspend states, including the “stop motor” state. If the motor communications cease and create the issue, another error will be generated when the system calls the “motor stop” state as part of the suspend process.
The error handler would re-enqueue the suspend states and an infinite loop would occur. A good error handler catches the first error and does not resolve the remaining errors. A good error handler also rearms itself at the end of the shutdown states.
5) Logs errors
Often, clients or end users will call support after seeing error messages, but they’re unable to relay the exact messages because they didn’t read them in full. The description of operation may help, but it often isn’t useful. A good error handler will log errors so they can be reviewed and analyzed. It will also provide the operator with a recall function to open the error log file and display errors. In addition, a good error handler logs all the errors, not just the ones that caused the error resolving to occur.
The log file can provide great insight into the scope and cause of issues. For example, if the error occurred when writing an analog output, the error log may show that all DAQ commands returned an error. That in turn may suggest the root issue has to do with the whole DAQ device and not just the AO portion of the system.
To continue learning about error handling, download our handbook below.
