Intended use of Error Clusters?

[EduNI]

I have a question regarding the intended purpose of Error Clusters.  It is clear that you should use error clusters and the LabVIEW error mechanism for catching and dealing with "internal" errors such as unable to open a comm port or even an unintended divide by zero.  For the purpose of this question, I am categorizing these types as internal errors.  However what about "process errors" such as the 'user opened the door' while a test was running? Is it "proper" LabVIEW programming to use the LabVIEW error mechanism together with error clusters to catch, propagate and deal with such errors or is better to create a separate error handling mechanism?  If the latter, then does anyone have any useful tips (or better, links) on implementing such an error mechanism?

[BowenM]

As a general rule, the error cluster is reserved for programmatic errors.  Something went wrong with your application and you need the ability to respond. What you are calling "process errors" are usually handeled within a state machine.

I advise against using the error cluster for this type of capture.  The reason being:  something passed in on an error cluster will often mean "there was an error - don't execute this code".  A process error means "something happened to my test. Execute the following code to shutdown correctly"

[Bob_Schor]

To my mind, there is a difference between an "execution error" (such as dividing by 0, attempting to open and read from a non-existent file, or trying to enqueue an element after the Queue has been released), things that logically prevent the Program from executing, and "Operator Errors", pushing the Start button before disengaging the Brake, or while a Door Interlock is open, doing tests out of order, etc.

Most LabVIEW functions (and thus most user-written VIs that make good use of the Error Line) will "do nothing" if an Error is present on input.  In the case of an Operator Error, you want code to execute, but it should be your code that alerts the Operator to Fix the Problem (such as popping up a Dialog Box that says "Close the Door, Dummy!").

Even better is to strive for "Idiot-proof Code" -- if you have a Door Interlock, disable (or make invisible) the Start Button until the Door is Closed.

Bob Schor

[RavensFan · Accepted solution]

If it was me, I would not put the "process" errors in to the error wire.  I would consider a process error an expected part of the normal operation of your code, while I would leave the error wire alone to handle errors within the programming that you wouldn't expect.  You'd run the risk that an earlier "expected" error from the process would override a more significant unexpected error within your program that prevents you from seeing it and handling it.  Also, most LabVIEW functions have what is called "standard error functionality" which means they don't execute on an incoming error.  (Why would you want to try reading from a file, if the open file function just upstream had an error while trying to open it?)  But if you have a "process" error, running down that error wire, it would prevent many of those downstream functions from executing.

I would just create your own wire to handle your process errors.  It could be a simple string or number.  But perhaps you want it to be a cluster.  You can structure it however you'd like.  I would be careful though that any cluster that consists of boolean, integer, string in that order will automatically look like a regular LabVIEW error wire with the mustard color.  That could be confused with your actual LabVIEW program error cluster.

[jamiva]

Slightly off topic, but when or under what circumstances would you use "Custom Error Codes"

[EduNI]

Thanks for all the good feedback.  Good stuf in each answer but can't mark them all as Solution 🙂 So summarizing my take-aways:

• Using Error Clusters for operator errors is a bad idea, it will prevent the execution of downstream on code that needs to be executed.
• Process error should be handled separately by your own wire (string, number or cluster) and as part of your code's state machine.

Thanks. All makes good sense!

[RavensFan]

I think you summarized that well.  Thanks for marking mine as a solution, but actually you can mark multiple posts as the solution.  Just click on the Solution button for the other messages after you've marked the first.

[BowenM]

---

@jamiva wrote:

Slightly off topic, but when or under what circumstances would you use "Custom Error Codes"

---

I use Custom Error codes quite frequently. Some examples...

I have a VI that will open AcroFields (editable fields) in a PDF and tag them.  I throw a custom error the operator attempts to tag a field that doesn't exist.

I wrote a variable library for one of my applications.  If the value of a variable that doesn't exist is requested it throws an error.  Similarly, if you attempt to add a variable that already exists.

Sometimes you communicate with hardware (RS232) that has it's own special error codes returned if the device isn't functioning properly.  I will frequently write an error handler that converts the device error into a custom error code.

Just to name a few 🙂

[jamiva]

Thanks for the clarification. I misinterpreted the previous replies. It sounded like using custom error codes within error clusters was not good programming practice. (kind of like stacked sequences being available but not advisable to use).

[crossrulz]

---

@jamiva wrote:

Thanks for the clarification. I misinterpreted the previous replies. It sounded like using custom error codes within error clusters was not good programming practice. (kind of like stacked sequences being available but not advisable to use).

---

I often use them for programming errors such as trying to set an invalid value or special hardware errors (instrument sent an invalid message).  Test results I will only throw errors if it is a critical error such as the UUT is drawing too much current (make sure you turn off the power supply before anything else and go straight to shutdown).