Global and Local Error Handling
Global and Local Error Handling
By Jonas Mäki
Where should errors be handled?
This question probably has many answers depending on who you ask. I will be looking from the developer’s point of view with the operator in mind.
I like to handle as many of the errors as I can locally so that the operator doesn’t have to know that errors have occurred. Any errors that a specific piece of code can’t handle locally will need to be sent to an error handling process.
What is local error handling?
Local error handling is when a function or process can handle an error directly and preferably solve the error without the user knowing the error occurred in the first place.
If it takes some time to rectify the error the user needs to be alerted in some way, with an LED or busy cursor for example. This will give a better understanding of what the code is doing and not seem like it’s hanging or freezing.
An example of a locally handled error could be reconnecting to hardware if communication with that external hardware failed. Retry connecting a certain number of times (I like to make it configurable how many times) before sending the error information to a global error handler. When a local process or function reports a fatal error that it can’t recover from the process should go back to an idle state if it was launched from another application (for example, your program is a microservice) or shut down as gracefully as possible if the process is started from another process in the same application.
What is global error handling?
Global error handling or just an error handling process is exactly what it sounds like: a process that handles errors. An error handling process has some way of communicating the occurrence of an error with the error handling process. The handler needs to log and or report this error. It’s also good if a broadcasting functionality exists to let the application know about the occurrence of a specific error, preferably with fatality levels.
Errors that are logged and/or reported should include at least what, when, and where the error occurred. Why the error occurred is for you as a developer to figure out. If the error should be logged or reported depends on the type of software release. Generally, logging is fine but if the software is used by many users/stations and systems are not easily accessible a report to the software manufacturer would be preferred. You’ve all seen the LabVIEW crash report window at some point, and this is a good example of a very global error handler.
For the most part, the raw LabVIEW error codes and windows shouldn’t be displayed directly to the end user, as this information tends to be confusing. Instead, let them know that an error has occurred, and optionally open error windows explaining errors on user action.
How to react to error handling broadcasts?
It’s the task of the calling software or main program to decide what to do with different levels of errors. On the most fatal/unknown errors, the program should close all processes and let the operator know that a fatal error occurred and point them to the error log location. If applicable, you can also ask them to send the report to the software manufacturer.
How to improve your deployed software with error handling
If a proper error handling process exists, the program can evolve with upgrades. When the developers get knowledge of errors that occur bugs can be corrected, and local error handling can be added to take care of the errors that may sometimes appear so that software will perform better over time.
Example of implementation of an Error handler
This is a simple yet very effective error handler that is easy to initiate and easy to communicate errors, and the logging is selectable between the temp folder in files and the windows event viewer. I tend to as this log can only be deleted in full and not partly.
Before going into the actual error handler, the design chosen for it is the OpenGDS Active Object design pattern with Events.
More information on this can be found at opengds.github.io. The class is set to be a singleton class.
Functionality of Error Handler
The Error handler.lvclass has six public functions. Init and CleanUp
are creating and destroying the error handler, respectively.
With ControlProcessWindow.vi you can open the error handler process window. If OpenProcessOnError is executed with a true value, the
process window will display automatically. This is usually only used
when debugging.
ReportError.vi can be placed anywhere in your application and will
send any error coming on the input error cluster to the error handler.
GetErrorBroadcastEvent.vi is used to register an event structure to
listen to occurrences of errors reported to the Error handler.
HandleErrors.vi is an example of application code calling the error handler process.
When errors are reported to the error handler and the window is opened either automatically or manually. All errors will be displayed. The amount occurrences and if they are warnings or errors are also displayed.
The broadcast of ErrorOccurred is used to light a LED to notify the user that an error occurred.
Error handler Process
In the Error handler process, which is mostly generated from the active object template, there is a CMD state that receives the errors reported and responds with a broadcast to an event queue from the process. The error is also added to the error map. The next step in the error handler is to update the list, then log the error, and then display the error handler window, if automatic.
Update of the error list with code, count, status, and source.
Logging is either to windows event viewer or to log files. There is a support class that handles everything with the log file and all that comes with that.
Expansion
I already talked about reporting errors directly to you as a software manufacturer and this is not part of this very simple error handler. The process could be expanded with this logic, and it could also be expanded with error levels and probably a lot more. This code is a good starting point to create great global error handling in your application, but don’t forget that errors need to first be handled locally if you can.*
Download the code referred to in this post.