Clear specific error

[David_L]

Good programming practice says to handle your errors.  If you want to clear a specfic error, you have to do some variation on the following code:

Since this can be pretty cumbersome in your code, I would love to have a Clear Specific error VI/function that will do exactly this.  It can also be polymorphic and accept an array of multiple errors.  To make it even better, you could probably merge it with the existing clear error VI and set it up where if the error input is empty, it clears all errors.

CaptainKirby made a nice community example that does all this, but I'd like it to be on the palette for everyone to use...

https://forums.ni.com/t5/Example-Code/Clearing-a-Specific-Error-From-The-Error-Cluster/ta-p/3517242

[jcarmody]

The Specific Error Handler will do this, and more.  It's the only Express VI that I frequently recommend.

---

The Specific Error Handler (SEH) reference library provides tools for handling specific error codes in an organized fashion. The SEH consists of a configurable Express VI that helps you handle specific errors and subVIs that categorize errors for use by a central error handler.

---

[David_L]

Hrmm, that's a pretty good VI.  But unfortunately still not included in LabVIEW.  I like to have these things part of LabVIEW so that when I go from computer to computer, or upgrade, I don't have to re-add the basic functions.  Also sending code to people or posting examples always requires including those VIs 😞

[CMal]

I know this doesn't help everyone, but there is a Clear Specific Error VI included in the LabVIEW Robotics Module at "<LabVIEW>\vi.lib\robotics\Utilities\Clear Specific Error.vi".

[Daklu]

Kudos because SEH should be part of the default palette.

[JackDunaway]

This is definitely an area for improvement, but I'm going to lean toward the synthesis of Allow Error Case Structure to Handle Specific Errors and Error Code Case Selector. Why? 1. This provides more generic and flexible method of handling specific errors, 2. Keeps the G language slim and trim by not needing to add another functional primitive, 3. Presumably, you ought to be wiring that error cluster into a Case Selector anyway, and 4. I like to wire things into case selectors. Kudos for raising awareness of this common problem, but beefing up case structures is going to be a better long-term solution.

[Daklu]

@Jack

"Keeps the G language slim and trim by not needing to add another functional primitive,"

The assumption is a 'slim and trim' palette is better than 'slim and trim' primitives.  In some cases I agree adding functionality to a primitive is useful--in other cases (such as this one) I don't.

"Presumably, you ought to be wiring that error cluster into a Case Selector anyway"

Why?  If my only purpose is to ignore a specific error returned by a sub vi, what point is there in wiring the sub vi's error out terminal to a case selector?  Having a "Clear Specific Errors" sub vi is much more clear than wiring into a case selector.

"beefing up case structures is going to be a better long-term solution."

I completely disagree.  Adding functionality to a primitive to deal with special cases (even common special cases) still adds complexity to the primitive and to the language overall.  Overloading primitives with right-click options appears to be generally accepted on the idea exchange as the preferred way to add functionality.  I disagree with that philosophy.  Generalized solutions that try to address all situations often end up being less flexible/useful than a family of specific solutions.

[DR_redviking]

While it is not a documented VI, the "Error to Warning.vi" function found in "vi.lib\Utility\error.llb" has been available since 7.1 (to my knowledge).  It performs a similar function, but has a limited number of error code inputs (only 4).  

I don't understand why NI never added this very useful VI on the Dialog and Errors palette, though.  

This VI can easily be modified to accept an array input and clear the errors rather than convert them to a warning.

[ReneW]

Good idea.

I would recommend to add a Boolean output to indicate if a specific error was found and cleared.

[Mark_Yedinak]

I would like to see this idea combined with the one posted here. Combining these two ideas cleans up the block diagram and provides and easy way to achieve a very common task.

[David_Grucza]

Doesn't the General Error Handler already do this, or am I missing something?