Error Handling in a Sequence of Critical Tasks

Today, I was helping out on a new feature for VIPM 2010 (which is going to knock your socks off when we release it, but that’s a different story).

In VIPM, after packages are installed, we want to perform a couple of tasks:

1. The first task is the new feature, so I can’t talk about it yet.  Let’s pretend it’s called Fragmenting Whetstones.
2. The second task is to refresh the LabVIEW palettes.

The order of these operations is important, and we want to refresh the palettes even if whetstone fragmentation produces an error.  But the “default” way of chaining errors in LabVIEW doesn’t produce this behavior.

The Problem: Chaining errors prevents execution when errors occur

In LabVIEW, we typically “chain” the error clusters of a sequence of calls to functions or subVIs. This is generally good practice for a couple of reasons:

1. It makes the dataflow order of execution clear, enhancing readability.
2. Downstream operations don’t execute if an upstream error occurs, which is typically what we want.

In this case, however, we want the tasks to execute in order but we also want Critical Task B (Refresh Palettes) to always execute.  And above all, we want to make sure that if an error does occur, we don’t lose that error out information.

The Solution: Clear and merge errors so that all nodes execute and all errors are captured

The solution is to use Clear Errors to make sure that there is no error flowing into any task.  Then, we call Merge Errors to merge each of the tasks’ errors, giving priority to the upstream error and upstream tasks (Merge Errors gives priority to errors on its inputs from top to bottom).

Hopefully, in VIPM 2010 you won’t actually see the results of this tip (an error dialog) — I’m going to work hard to make sure we get all the bugs out of the new Whetstone Fragmenter before any customers see it .