Question regarding Error Wire in some OpenG subVIs

[kgaliano]

Good afternoon,

 

Some subVI's of the openG package in Labview 2012 use an error guard to enclose their content (i.e., a case structure with an error wire as the boolean input). In some subVI's, in the "No Error" case of the error guard, the error wire is not propagated through (i.e., the code uses a "no error" constant somewhere else to continue the error wire. One example of this is in the subVI of "Get Data Name from TD__ogtk.vi" in version 2012. I know that for most practical applications, this is alright because if there isn't an error input, then a "no error" constant is almost identical to the input.

 

However, I was wondering if there was a way around this for when one manually introduces warnings in one's code (i.e., suppose I have a subVI that checks a condition to introduce a warning to alert the user of a potential problem, and then at some point this error wire goes into Get Data Name from TD__ogtk.vi, wouldn't the warning become lost?).

 

Thank you.

 

Kevin

 

 

[drjdpowell]

Many LabVIEW developers don’t use warnings, and I recently saw a talk where they were described as an “anti-pattern†(a common software design that has more negatives than positives and should be avoided).  You are right though, that a toolkit like OpenG shouldn’t be dropping warnings that pass through it.

[ShaunR]

Many LabVIEW developers don’t use warnings, and I recently saw a talk where they were described as an “anti-pattern†(a common software design that has more negatives than positives and should be avoided).  You are right though, that a toolkit like OpenG shouldn’t be dropping warnings that pass through it.

 

Yawn. We are back to the beginning of the circle then. Every few years someone decides that this or that is a bad idea so as to be "progressive" then a few years later another person decides it is the opposite again. It's a non argument in the same way as how many different types of errors should we have?

 

I use warnings to tell users/developers that data is being dropped and an error is not appropriate for that.as it is a designed feature to protect the server/client.

[drjdpowell]

I use warnings to tell users/developers that data is being dropped and an error is not appropriate for that.as it is a designed feature to protect the server/client.

 

The speaker who called it an anti-pattern was Dmitry, at the recent CLA Summit in Berlin.  I don’t think he posts on LAVA, but I suspect he might argue that calling code should decide if “data being dropped†is acceptable or not and thus either dropped data should be an error (with calling code forced to decide what to do) or it should be a separate output, such as a “data dropped†boolean, which calling code should immediately either handle or explicitly choose to ignore.  

[ShaunR]

The speaker who called it an anti-pattern was Dmitry, at the recent CLA Summit in Berlin.  I don’t think he posts on LAVA, but I suspect he might argue that calling code should decide if “data being dropped†is acceptable or not and thus either dropped data should be an error (with calling code forced to decide what to do) or it should be a separate output, such as a “data dropped†boolean, which calling code should immediately either handle or explicitly choose to ignore.  

 

That's a partitioning argument but more importantly it's just that sort of thinking that means we have an error emitted reading an entire text file which is a glorious pain in the backside .

[kgaliano]

Thank you for your replies.