LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Clear specific error

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:

 

19165i312FA51360BCBCDF

 

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...

http://decibel.ni.com/content/docs/DOC-3515

 

21 Comments
Trusted Enthusiast

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.


Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Active Participant

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 :-(

Active Participant

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".

Active Participant

Kudos because SEH should be part of the default palette.

Trusted Enthusiast

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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Active Participant

@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.

Member

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).  

 

20641i87C0AEA19BF95403

 

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.

20643i53F1BAD3F783BC76

Member

Good idea.

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

clear specific error with indicator

 

Trusted Enthusiast

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Member

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

 

General Error Handler.JPG