LabVIEW Style Challenge - Error Wires

[Kevin_Price]

---

@paul_a_cardinale wrote:

---

---

This messy construct is completely unnecessary: 

True, but I like doing *some* unnecessary things when I think they help clarity.  One that's come up on the forums before is that I'll often do the following kind of thing with integer constants:

The function wants an i64 and my constant already *is* an i64.  But I put the "convert to i64" in there anyway to make the datatype explicit to any future code-editor, such as very possibly a forgetful me.  I expect the compiler turns that into a no-op anyway.

Above, back when I was doing things that involved distributing source code, I would habitually add a "Clear Errors" after any error out that wasn't meant to propagate.  It didn't matter in my own dev environment where I always turn off the automatic error handling & dialogs.  But it *could* matter when others ran the source in their environment.

Just food for thought...

-Kevin P

[JÞB]

---

@PragmaTest wrote:

---

@paul_a_cardinale  a écrit :

---

@Taggart wrote:

---

This messy construct is completely unnecessary: 

As with other 'close' functions, "Close Config Data" will close the reference* even with an incoming error.  All you need is this:

* However an incoming error would prevent "Close Config Data" from writing data to the file; but since this code only reads data, that doesn't matter.

---

It's a matter of philosophy.

You say that because you have access to the diagram of the close function.

As a TestStand user, I always make silent cleanups.

---

That scares me.   😨  

I really think that if you always clear Error Out because you don't like using the default TestStand Step.error Step Configuration options that you would be better served by simply creating Custom LabVIEW Step Types with the Expression Step.Error==<FALSE, 0, "">

Backing up to Paul's comment about preventing the file write inside Close. (EDIT: See note 1)This is another reason to have a specific error chain for each API (Configuration File, Generate Event, Enqueue)  IIRC, the only ways you can get an Error from an INI API Read are:

• Refnum to the Configuration Data Queue Object becomes invalid
• Data value is not of the expected Type (not really easy to get with a String datatype polymorphic instance when reading from text strings but quite possible with every other datatype an ini file can hold)

For any keys written to a valid Config file data queue object refnum either; the datatype selects the correct polymorphic instances or, the compiler breaks the VI. The file contents cannot be changed until the flawed VI is debugged.

NOTE 1: assumption is that nobody tries using anything on the 8.5 and prior Configuration File API VIs.  They are depreciated for good reasons and work entirely different from The 8.6 and later API.

[PalanivelThiruvenkadam]

........................

[PragmaTest]

---

@JÞB  a écrit :

---

@PragmaTest wrote:

---

@paul_a_cardinale  a écrit :

---

@Taggart wrote:

---

This messy construct is completely unnecessary: 

As with other 'close' functions, "Close Config Data" will close the reference* even with an incoming error.  All you need is this:

* However an incoming error would prevent "Close Config Data" from writing data to the file; but since this code only reads data, that doesn't matter.

---

It's a matter of philosophy.

You say that because you have access to the diagram of the close function.

As a TestStand user, I always make silent cleanups.

---

That scares me.   😨  

I really think that if you always clear Error Out because you don't like using the default TestStand Step.error Step Configuration options that you would be better served by simply creating Custom LabVIEW Step Types with the Expression Step.Error==<FALSE, 0, "">

---

With TestStand, I always check Ignore Runtime Error on cleanup steps

[paul_a_cardinale]

---

@PragmaTest wrote:

---

@paul_a_cardinale  a écrit :

---

@Taggart wrote:

---

This messy construct is completely unnecessary: 

As with other 'close' functions, "Close Config Data" will close the reference* even with an incoming error.  All you need is this:

* However an incoming error would prevent "Close Config Data" from writing data to the file; but since this code only reads data, that doesn't matter.

---

It's a matter of philosophy.

You say that because you have access to the diagram of the close function.

As a TestStand user, I always make silent cleanups.

---

No, I say that because I have access to context help (Ctrl-H).

[paul_a_cardinale]

---

@Kevin_Price wrote:

---

@paul_a_cardinale wrote:

---

---

This messy construct is completely unnecessary: 

True, but I like doing *some* unnecessary things when I think they help clarity.  One that's come up on the forums before is that I'll often do the following kind of thing with integer constants:

The function wants an i64 and my constant already *is* an i64.  But I put the "convert to i64" in there anyway to make the datatype explicit to any future code-editor, such as very possibly a forgetful me.  I expect the compiler turns that into a no-op anyway.

Above, back when I was doing things that involved distributing source code, I would habitually add a "Clear Errors" after any error out that wasn't meant to propagate.  It didn't matter in my own dev environment where I always turn off the automatic error handling & dialogs.  But it *could* matter when others ran the source in their environment.

Just food for thought...

-Kevin P

---

When I want to make it clear what a constant type is, I just use a label.

[SteenSchmidt]

---

@PragmaTest wrote:

---

@paul_a_cardinale  a écrit :

---

* However an incoming error would prevent "Close Config Data" from writing data to the file; but since this code only reads data, that doesn't matter.

---

It's a matter of philosophy.

You say that because you have access to the diagram of the close function.

As a TestStand user, I always make silent cleanups.

---

No need for the block diagram, Close Config Data tells you in its help: "With the following exception, this input provides standard error in functionality. If an error occurs before this node executes, the node only closes the reference passed to it."

Error handling is not a matter of philosophy. You should adhere to a few strict rules always:

1) Release all data (e.g close references) you yourself create (except if your job is to persist data), and don't release anybody else's data (except if your job is to release data for others). There is an important gotcha in this regard: If you receive an input reference, and your functionality includes you outputting that reference as part of your output data, then you need to internally create your own copy of that reference for you to output. Don't just output the reference you were given, because that reference's lifetime is controlled by your caller that does not know that the reference is now also part of another dataset (your output).

2) Handle errors you can internally, and don't tell anybody about them (except if you have an internal log functionality that forces you to log runtime occurrences).

3) Output the errors you can't handle internally, and shut yourself down on the way out. It's your caller's responsibility to fix what comes out of you and restart you, if they so choose.

4) If at all possible, you should translate your internal errors and make them your own before you output them. This hides your inner implementation and allows you to put context on your errors. Context only you know, and which could help your caller.

And therefore...

5) Always disable 'Automatic error handling'! Do proper error handling instead of leaving on such a timebomb because you're lazy.

[JÞB]

---

@paul_a_cardinale wrote:

---

@Kevin_Price wrote:

---

@paul_a_cardinale wrote:

---

---

This messy construct is completely unnecessary: 

True, but I like doing *some* unnecessary things when I think they help clarity.  One that's come up on the forums before is that I'll often do the following kind of thing with integer constants:

The function wants an i64 and my constant already *is* an i64.  But I put the "convert to i64" in there anyway to make the datatype explicit to any future code-editor, such as very possibly a forgetful me.  I expect the compiler turns that into a no-op anyway.

Above, back when I was doing things that involved distributing source code, I would habitually add a "Clear Errors" after any error out that wasn't meant to propagate.  It didn't matter in my own dev environment where I always turn off the automatic error handling & dialogs.  But it *could* matter when others ran the source in their environment.

Just food for thought...

-Kevin P

---

When I want to make it clear what a constant type is, I just use a label.

---

Sometimes I even make those into an optional control with a default value and show as Icon on the BD to make the I64 look bigger and better. 

I know, I'm incredibly inconsistent.  Required and Recommended inputs and all outputs are shown as Terminals while Optional inputs I show as Icons on the BD.  It has advantages😉, And yet, I still can't remember to use Icons for unwired indicators! 

[Jacobson-ni]

Error wiring depends on requirements of course. I figured if the Event and Queue terminals were both required, I should default to thinking you would want to know if there was an error.

Timeout probably doesn't actually matter because I don't know anyone who sets a max queue size for the standard queue but I've hung enough RT/FPGA code to leave the timeout at -1. Timeout input is optional and defaults to 100.

Biggest wastes of time were messing with the z-order of wires and aligning the bottom of the array with the bottom of the for loop. You have to inflate those project hours somehow 🙃.

LabVIEW style guide I follow suggests book case for names. I don't care too much about which naming convention is used but I think it has to be the same throughout the project. I worked on a project where the tech lead would request changes if you didn't use the Ctrl+F quick drop shortcut on your VIs and after getting used to that I'll make sure to use it before saving/committing the VI.

[PragmaTest]

---

@SteenSchmidt  a écrit :

---

@PragmaTest wrote:

---

@paul_a_cardinale  a écrit :

---

* However an incoming error would prevent "Close Config Data" from writing data to the file; but since this code only reads data, that doesn't matter.

---

It's a matter of philosophy.

You say that because you have access to the diagram of the close function.

As a TestStand user, I always make silent cleanups.

---

No need for the block diagram, Close Config Data tells you in its help: "With the following exception, this input provides standard error in functionality. If an error occurs before this node executes, the node only closes the reference passed to it."

Error handling is not a matter of philosophy. You should adhere to a few strict rules always:

1) Release all data (e.g close references) you yourself create (except if your job is to persist data), and don't release anybody else's data (except if your job is to release data for others). There is an important gotcha in this regard: If you receive an input reference, and your functionality includes you outputting that reference as part of your output data, then you need to internally create your own copy of that reference for you to output. Don't just output the reference you were given, because that reference's lifetime is controlled by your caller that does not know that the reference is now also part of another dataset (your output).

2) Handle errors you can internally, and don't tell anybody about them (except if you have an internal log functionality that forces you to log runtime occurrences).

3) Output the errors you can't handle internally, and shut yourself down on the way out. It's your caller's responsibility to fix what comes out of you and restart you, if they so choose.

4) If at all possible, you should translate your internal errors and make them your own before you output them. This hides your inner implementation and allows you to put context on your errors. Context only you know, and which could help your caller.

And therefore...

5) Always disable 'Automatic error handling'! Do proper error handling instead of leaving on such a timebomb because you're lazy.

---

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.

I know we are prone to have a straight error wire, but let me 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.

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

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.