Error handling architecture

[Greg Hupp]

Working with a large app that spans several parallel running VIs (a master VI and a couple dynamically called VIs) and trying to implement a quality error handling/logging functionality (the previous version didn't have one and I hacked something into it as an intermediate update!)

Currently, I have a produce consumer, that has a small error VI that triggers and event that is handled in the producer loop...the action can be handling/logging etc.

Anyone have any clever error handling architectures or ideas that might be of use?

[Mark Smith]

Working with a large app that spans several parallel running VIs (a master VI and a couple dynamically called VIs) and trying to implement a quality error handling/logging functionality (the previous version didn't have one and I hacked something into it as an intermediate update!)

Currently, I have a produce consumer, that has a small error VI that triggers and event that is handled in the producer loop...the action can be handling/logging etc.

Anyone have any clever error handling architectures or ideas that might be of use?

See if this helps (LV 8.6.1)

Mark

ErrorLogger.zip

[Greg Hupp]

See if this helps (LV 8.6.1)

Mark

ErrorLogger.zip

Yeah...this is similar to what I had...but wrapped up a little better! Thanks.

[Daklu]

Working with a large app that spans several parallel running VIs (a master VI and a couple dynamically called VIs) and trying to implement a quality error handling/logging functionality (the previous version didn't have one and I hacked something into it as an intermediate update!)

Currently, I have a produce consumer, that has a small error VI that triggers and event that is handled in the producer loop...the action can be handling/logging etc.

Anyone have any clever error handling architectures or ideas that might be of use?

Inserting consistent error handling into a project after the coding is mostly complete can be tricky. In those cases I'll create a 'RaiseError' sub vi that takes an error code as an input. Internally the RaiseError sub vi looks up the correct error description for that error code and constructs an error cluster, which it sends out on the error wire. I like to use "Create Error Cluster from Code.vi" from vi.lib, but you can build it however you want.

If I'm creating the application from scratch I try to build a more unified approach centered around my Message library. "Expected" errors are immediately trapped (meaning the error wire is cleaned), packaged into an ErrorMessage object or ErrorMessage subclass object, and put on the message queue to be be handled by the message handler. "Unexpected" errors propogate on the error wire to the start of the next loop. When my DequeueMessage.vi detects an error on the input, it traps the error, packages it in an ErrorInMessage object, and sends that out to the message handler. The queue remains unchanged. If the Dequeue primitive generates an error message, the error is trapped, packaged into a QueueErrorMessage object, and sent to the message handler. The ErrorInMessage and QueueErrorMessage classes are subclassed from my ErrorMessage class, which is in turn subclassed from my Message class. All of these classes (as well as my MessageQueue class) are part of my Message library. I typically derive new classes for each application specific error, but they can be packaged into the generic ErrorMessage object also. I don't think my approach is unique but I do feel like I have better control over error handling when I do it.

My only other comment is that you'll get more reuse mileage out of your error logging code if you make sure it is independent from your error handling code. Error handling code is typically application-specific; error logging code can easily be reused across projects. I favor using the error logger inside the error handling code--others may have different ideas.