LabVIEW Style Challenge - Error Wires

[paul_a_cardinale]

---

@smi38 wrote:

---

---

...

My cleanup philosophy is very consistent.

I perfectly know the two clear errors have no functional incidence here.

You don't always have access to the diagram, and you don't always have a proper help.

The two clear error functions are here to explicitly show that the close will be done regardless of error input, and will never output an error.

Sure, when you don't know what a cleanup function will do if it receives an incoming error, you need to ensure that it doesn't get one.  But in my opinion, it's never called for to do something explicitly when you know it will be done automatically, and when that behavior is common knowledge and well documented.  (Well, OK; I don't really care how common the knowledge is, as long as it's well documented.)

Also, when you write a cleanup function, you should make sure that it will always clean up regardless of any incoming error.

I'm not consistent in the way I remove screws.  If I need to use a screw extractor, I'll use one; if not, I'll just use a screwdriver.  That's not consistent; but it's sensible.

[SteenSchmidt]

---

@smi38 wrote:

---

---

My cleanup philosophy is very consistent.

I perfectly know the two clear errors have no functional incidence here.

---

Then they shouldn't be there. They're noise to the next developer, they add complexity when considering maintenance, they add unnecessary dependencies, they potentially add a performance hit both at load and at runtime.

Functionality removed is the best improvement to code, because they are the opposite to the above.

You don't always have access to the diagram, and you don't always have a proper help.

---

Exactly, you should act on the info you have available. In this case you had info that says you don't need to clear the error. If you didn't have any info, you'd have to act differently to make sure your close code did run on error.

Repeating the same thing mindlessly is bound to get you into trouble. The same way that some people always surround their code with an error structure. That's not always the right functionality. Sometimes your code should run even on error. Sometimes none of it should. Sometimes some of it should. Sometimes something else should run. Yet, I see some people have a template with an error structure already in place. That's all I'm saying.

The two clear error functions are here to explicitly show that the close will be done regardless of error input, and will never output an error.

---

Why shouldn't Close output an error? What if the closing failed? Templating can lead to these kinds of oversights.

I have to add that we are here to discuss our error management habits, and I'm a bit confused about the tone employed by some folks here...please be kind, it's not a competition.

---

Absolutely. I apologise if I've offended you, that was not my intent. My intent is neutral. There aren't many mistakes I haven't done or bad habits I haven't had or still have myself, so I don't pretend to be holy 🙂

[JÞB]

---

@smi38 wrote: ...take an example : imagine you have to use a driver, and this driver is deployed as a PPL with no diagram. Imagine that the close function have no help, and an error input will not set the voltage output off.

---

I imaged a PPL rejected for use due to lack of documentation. Use that as an example of how to approve code for use.

I reject the assumption that I MUST use bad code.  Rewrite the driver properly. 

• Another example : take a TestStand sequence, press terminate before having finished the setup : you will try to perform some cleanup actions which could not even be initialized resulting of these cleanup steps to output an error (and possibly display the TS error popup).

OK, the USER chose to Terminate the execution overriding the sequence developer's judgment (often for good reasons.)  The USER needs to make informed decisions about what consequences might occur.   Those TS error popups are just dandy little helpers in that case.

[whitenoiz]

Since this looked like fun and learning, I had to fire up LV23 right away to check out the new features. Made no assumptions and kept it simple. Just the usual layouting meditation. 😊

I love it when labels are aligned with the nodes, looks less edgy. Can anyone tell I'm a right-brainer?

[JÞB]

@Matt

I like it alot....but, I go back and add a Write Key to default if "not found?" = T just to keep the file itself in sync with the code development.

[smi38]

---

@JÞB  a écrit :

---

@smi38 wrote:

• Another example : take a TestStand sequence, press terminate before having finished the setup : you will try to perform some cleanup actions which could not even be initialized resulting of these cleanup steps to output an error (and possibly display the TS error popup).

OK, the USER chose to Terminate the execution overriding the sequence developer's judgment (often for good reasons.)  The USER needs to make informed decisions about what consequences might occur.   Those TS error popups are just dandy little helpers in that case.

---

In my opinion the TS error pop-up is not acceptable in a production environment for this case. I can't spend my life treating support tickets just because an operator hit the terminate button (and has the right to do so) while instruments were not all set up.

I just try to cleanup, and if it gives an error I clear it with "Ignore Runtime error". Thus my life and the life of the operator is more simple.

---

@JÞB  a écrit :

---

@smi38 wrote: ...take an example : imagine you have to use a driver, and this driver is deployed as a PPL with no diagram. Imagine that the close function have no help, and an error input will not set the voltage output off.

---

I imaged a PPL rejected for use due to lack of documentation. Use that as an example of how to approve code for use.

I reject the assumption that I MUST use bad code.  Rewrite the driver properly. 

---

I think this is unfortunately not always applicable in real life.

I would add this is exactly the kind of tone I was talking about...

[Jacobson-ni]

---

@JÞB wrote:

@Matt

I like it alot....but, I go back and add a Write Key to default if "not found?" = T just to keep the file itself in sync with the code development.

---

That's probably a good idea.

In this example you would also have to ask if there's even a meaningful default you could use. Even if there was a meaningful default it may be a configuration you want the option to change but not make it super obvious to users (like some more "secret" LabVIEW INI tokens).

[Bob_Schor]

By the time I saw this, it was after dinner (yesterday) and after a few News shows.  I started on this, but fell asleep, and didn't get back to it until this afternoon.  I didn't "peek" at the other entries.

I'm something of a nut for clarity of viewing, hence my preference for Using Case to Help the Reader.  I also moved the "Key" inputs so they were "better associated" with the function using them.  I deliberately didn't wire the Error Line for the Queue Ref and Event Ref, since it's not clear to me that this would be what the User would want.  But this is supposed to be about "Style" -- curiously, the second book I read concerning LabVIEW (after Jim Kring's "LabVIEW for Everyone") was Peter Blume's "The LabVIEW Style Book", and still endeavor to fit every VI on a single screen (no longer 640 x 480, more like 1920 x 1080, but at 125% magnification for "older eyes").

Bob Schor

P.S. -- I didn't intend to, but after I posted, I noticed I "accidentally" partially answered the Bonus Questions ...

[smi38]

Derrick Bommarito has posted on LinkedIn something half similar to me as he didn't wire the error input of the close ini file.

[SteenSchmidt]

---

@smi38 wrote:

Derrick Bommarito has posted on LinkedIn something half similar to me as he didn't wire the error input of the close ini file.

---

Yes, and he would have had exactly the same functionality had he wired the error input, he would just have saved the error bundler after the Close.

And if he hadn't made the code much more complex with a For-loop (why would you send empty strings when your file read failed?), he could have skipped the error structure around it all and just used dataflow with the error wire. His code would have skipped almost instantly with 70% less code and a much simpler diagram. We are different there...

Derrick's code on LinkedIn for reference