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!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Error code case selector

CaseError.PNG

Would be nice to have an element selector with error case. No need to wire an unbundle element to connect the error code, then the Case structure becomes like a numerical values case selector.

15 Comments
Knight of NI
To clarify, are you saying that you wouild want multiple error cases so that a different case could run depending on the error code number?  Of course one error case would have to be designated the default error case.
Member
Yes exactly, my screenshot prototype is not the ideal, we should compare with unbundle before, with the error code wired to the case selector. Or the error status to be boolean. Then we can select to do some code regarding the error code.
Proven Zealot
How do you handle warnings? Do you have different cases for "error 2" vs "warning 2"? Do warnings just get ignored and the case structure does "no error" even though the code is non-zero?
Knight of NI

Aristos: That assumes that everyone uses NI's convention of warnings/errors, and not everyone does.

 

As for the idea:

 

I don't really see the need  for this, and I think this would actually complicate things. What happens when you decide to switch from code to the status, and you have more cases than just the 2 possible Boolean values?

Proven Zealot
The General Error Handler.vi follows that convention, and NI toolkits do return warnings. Any design that NI does will assume that paradigm.
Knight of NI

Aristos wrote:

 

Any design that NI does will assume that paradigm.


I know. My own personal opinion on that convention notwithstanding, my only point is that the rest of the world may not follow that convention and thus would not see it as a problem for this idea. In this particular case this would be in user code, not NI code, so why would the convention have any bearing? Even if this idea were implemented (which I disagree with anyway), NI wouldn't be able to use it because of the convention, so you would simply produce code the same way you do now. 

Member

I really enjoyed your comments, thanks to all. I realized that it's not that easy to propose now ideas for LabVIEW.

 

But I still think it could be simple to use that idea with codes only for errors, ignore warnings like it actually does. So even in "code mode" it would check for the status. Or perhaps clever people could figure out that it's better to have one more option to ignore or not the error/warning status.

 

For the switch back to "error status" with only two cases I think it should requires to define a "Default" case different than "No errors". As it's actually possible to remove case structure and popup a message to user to accept that he will lose all the other cases code.

 

You never wire a unbundle element to connect your error code to a case structure, to handle your different error codes?

Knight of NI

JICHFI wrote:

You never wire a unbundle element to connect your error code to a case structure, to handle your different error codes?


I have, but quite rarely. I can probably count the number of times on one hand. Given that I've been coding in LabVIEW since LabVIEW 2.something, I honestly can't see the need for this. But again, that's only my opinion - don't let that discourage you from supporting your case.

Member
I would like to know how you normally handle your errors.
Proven Zealot

smercurio_fc wrote:

> my only point is that the rest of the world may not follow that convention

> and thus would not see it as a problem for this idea. In this particular case

> this would be in user code, not NI code, so why would the convention have

> any bearing? Even if this idea were implemented (which I disagree

> with anyway), NI wouldn't be able to use it because of the convention, so

> you would simply produce code the same way you do now. 

 

I think you miss my point... the whole world doesn't have a choice about using a different convention. Suppose you write some DAQmx code and you want to trap error code 1850 -- DAQ Card On Fire (I made it up.) Suppose that some DAQmx subVI returns a warning 1850 -- DAQ Card Feeling Hot. You wire your error code cluster to the selection terminal and you put "1850" into the selection ring. Do you expect your case to execute only on the warning or only on the error or both? To implement this feature, LV R&D has to decide how many configuration options to expose and what behavior to have when these edge cases arise. Is it literally just checking the number (both warning and error trigger code)? Is it looking for the error bool to be true and the code to match (just error)? Is there some prefix that you type in front of 1850 that would mean catch the warning?