LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
JICHFI

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.

16 Comments
RavensFan
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.
JICHFI
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.
AristosQueue (NI)
NI Employee (retired)
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?

AristosQueue (NI)
NI Employee (retired)
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. 

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

JICHFI
Member
I would like to know how you normally handle your errors.
AristosQueue (NI)
NI Employee (retired)

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?