LabVIEW Style Challenge - Error Wires

[JÞB]

---

@altenbach wrote:

On a side note, I am impressed that a simple question turned into a 100 post thread (one more to go!).

(... and it's not even about religion or politics! I stayed mostly out of it because my programs don't generate errors 😄 JK)

---

I have to agree!  The better Style Guideline for Error Handling is: "Don't write bugs."  Then all 99 previous replies are simply moot.

Perhaps the GDevCon presentation should be titled "Style Guidelines for Error Handling (when you write bugs anyway.)"

[Yamaeda]

---

Perhaps the GDevCon presentation should be titled "Style Guidelines for Error Handling (when you write bugs anyway.)"

---

That's an excellent title! Please use that! 😄

[smi38]

As concluded before, my habit comes from TestStand Terminate + cleanup steps.

Consider this example :

SETUP

   Open instrument A

   Open instrument B

   Open instrument C

MAIN

   Action instrument A

   Action instrument B

   Action instrument C

CLEANUP

   Close instrument A

   Close instrument B

   Close instrument C

If Terminate is pressed while opening instrument A, a jump is done to cleanup group, then instrument A is closed, but instrument B and C output an error since they are not opened.

I want the Terminate button available for every user, I want the TS error pop-up enabled, but I don't want the error pop-up displayed in the previous scenario while terminating.

In TestStand there is no such thing as error input parameter.

In TestStand there is a step option called Ignore Run-Time Error.

That's why I activate this option on cleanup steps and it never ever gave me a single side effect.

But, I can understand that is not easily transposable in LabVIEW, since LV has an error data flow mechanism, no error callback mechanism and no native cleanup jump mechanism.

[SteenSchmidt]

---

@smi38 wrote:

As concluded before, my habit comes from TestStand Terminate + cleanup steps.

Consider this example :

SETUP

   Open instrument A

   Open instrument B

   Open instrument C

MAIN

   Action instrument A

   Action instrument B

   Action instrument C

CLEANUP

   Close instrument A

   Close instrument B

   Close instrument C

If Terminate is pressed while opening instrument A, a jump is done to cleanup group, then instrument A is closed, but instrument B and C output an error since they are not opened.

I want the Terminate button available for every user, I want the TS error pop-up enabled, but I don't want the error pop-up displayed in the previous scenario while terminating.

In TestStand there is no such thing as error input parameter.

In TestStand there is a step option called Ignore Run-Time Error.

That's why I activate this option on cleanup steps and it never ever gave me a single side effect.

But, I can understand that is not easily transposable in LabVIEW, since LV has an error data flow mechanism, no error callback mechanism and no native cleanup jump mechanism.

---

Your problem is basically that you have too little intelligence in your TestStand Close procedures, and are taking a shortcut instead of completing your code. You are asking 'Close Instrument B' and 'Close Instrument C' to close instruments that haven't been opened. They must error out in this case, it's not the correct action to suppress their error messages. What when they can't close instruments that are actually opened?

What you should do is only close what you have opened, and then be happy about your functions returning errors when they can't do what you have asked of them.

Either improve your setup/cleanup logic in the sequence, or build more context awareness into your instrument management software.

A mature software developer has realized that creating software is a lot of tedious work. The "creative" part is fun, architecting the sunshine scenario. The tough part comes when you have to make all the failure modes also work. Like a painter needing to mask off, finish with clear coat, and clean their tools. If you don't do it, the fun part quickly stops being fun.

This is universal, it has nothing to do with programming/scripting language: Every function must do exactly what it advertizes, and it must tell you if it failed. No hidden side effects. This takes a lot of stamina to pull off, and not everybody can muster that. That's why so much software fails when you look around you on everyday things. Destinguish yourself from the crowd: Strive to be a great programmer.

[Broken_Arrow]

This is the answer, no reason to look further. 

[JÞB]

• CLEANUP

     Close instrument A

     Close instrument B

     Close instrument C

IFF Session handle is Valid = TRUE

You can even write it in LabVIEW 

You are getting bit by the embedded 

IFF Error GOTO statement in TestStand.  Did I mention that there are a few things that I feel were not quite right in TestStand.   The original LabVIEW 5.0 Test Executive handled cleanup nicer but VISA was still infantile.  

[smi38]

The suggestion to add a precondition is exactly the same thing as testing the validity of the refnum in the ini file challenge.

As far I see nobody's has done it in the screenshots, nor NI in the close ini file function.

Edit : I remember a recent message of Aristo's queue where he explained why Not A Refnum is often misused.

[SteenSchmidt]

---

@smi38 wrote:

The suggestion to add a precondition is exactly the same thing as testing the validity of the refnum in the ini file challenge.

As far I see nobody's has done it in the screenshots, nor NI in the close ini file function.

---

Testing the refnum is the wrong way around. You should operate from deterministic certainty that you need to close the refnum or not: If you know that the refnum was newer opened, don't attempt closing it. If you know the refnum was opened, then attempt closing it. Live with the consequences of either action. If you test the refnum, then you'd miss the problem with somebody else having prematurely closed it.

It's a racing condition testing the refnum anyways: Someone might close it just after you're tested it, but before you attempt closing it. You'll hit an error anyways. Eliminate the racing condition by just closing the refnum and see what happens.

[smi38]

Ok, sounds good.

Now let see if I can (and want) change my habit in TestStand...because it's very easy to check the TS option, and I see no real interest to add extra precondition variables just for that.

If you take all the TS sequences on this planet I bet there are very few with a precondition on closing steps.

I can definitely change my habit in LabVIEW, which I am sure is a good news for pugnacious folks here 🙂

[JÞB]

---

@smi38 wrote:

Ok, sounds good.

Now let see if I can (and want) change my habit in TestStand...because it's very easy to check the TS option, and I see no real interest to add extra precondition variables just for that.

If you take all the TS sequences on this planet I bet there are very few with a precondition on closing steps.

I can definitely change my habit in LabVIEW, which I am sure is a good news for pugnacious folks here 🙂

---

I'll retract the precondition suggestion.  Bad idea I'm still on iteration 0 in the coffee loop this morning.

The comment about GOTO  in TestStand is however a valid point.  It "Should be" easy to determine how the Cleanup Group was entered (Read my signature line!) but I haven't seen a living example of a sequence Cleanup group that cared about the means of entry.  Sébastien sounds like he does care to have that information and act on it.

Am I tracking now, or do I need to iterate over Coffee++?