Conditional Error Ring

[JÞB]

Of course, the two examples would produce identical outputs.  One would take a bunch fewer clicks and BD space though.

[JÞB]

Error discrptinions can contain format specifiers!!!   ERs were developed  so we can add whatever type of info we want when an error is generated!

The user in that error needs to "read the friendly manual" and has not... an error condition... user "Schmuck" is a schmuck!

Yes, if user" %s" has read the manual and given a proper input to this vi, "no error" should be thrown.

[Ray.R]

tst:  I thought you'd like it 🙂

Jeff...  Now you really lost me..  Or did you...  You might be where I'm at...  I don't know yet..

Is the string to let an operator know the potential sources of that error?  Humm....

For instance:  An instrument throws an error because it is not on, thus it does not respond to *IDN?  and/or timesout to a TCP or GPIB request.  Error is set to TRUE....  If you're the developer of the SW...  You think "hey !!  what could cause such an error?  (because we do have to distinguish between an error and a failure... I put this because some programmers don't :mad: )

So you then add:  "schmuck!  Did you turn on the instrument? Did you connect the Ethernet or GPIB cable to the instrument and to the test PC? Did you do this?  etc.."

Is this what you are trying to say concerning the string input?

Sorry for asking so many questions..  I am trying to understand what this new idea is offering.   This is the longest discussion I've ever had before assigning a bloody Kudos!  😉

[tst]

Ray, ignore the behavior of the string and look at the original image in the idea without the string. The point is that the bottom code is the same as the top - if the input is F, then the ring outputs a No Error value (False,0,'') (which means that if unwired the input should be considered to be T). I did vote for this now, but I wouldn't be heartbroken if it wasn't around (although who knows, maybe when I move to >2011 I will find out this would be nice).

[Ray.R]

Agreed...  I think after all this Jeff deserves kudos.  I do like the idea, but was curious about the string terminal.

I just happen to work on a project where I offer debug suggestions when an error occurs.  I thought the string terminal would be a nice way of adding this.

[JÞB]

I suppose a link to the LabVIEW help file will help explain: The Error Ring and Custom error codes:

Yes, Those format specifiers in the custom error codes are great ways to give the user specific information on the error!

Sometime I assume new features are universally adopted and understood.  My appoloies.

[Brandyn]

I like this idea. I think it would go a long way with helping people be better at doing error handling in their code

[Darren]

National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.

[wiebe@CARYA]

Totally unexpected. Great idea. Would save me lots of work. The performance issue is just a bonus, convenience (less work to use) is the main part.

[JÞB]

Thank you for the explanation.   Of course I had not considered that the node must access all error files from several folders to throw "no error" 

The overhead of throwing an error is often, but not always buried in user interaction. 

I hate too say it but... This looks like a job for an Express.vi!

[wiebe@CARYA]

The idea would provide a better data flow, perform at least just as good and make the error ring easier to use.

Still don't see a downside...