LabVIEW Style Challenge - Error Wires

[JÞB]

---

@mcduff wrote:

Interesting, quite a bunch of impressive people on the submission list. My questions/observations:

1. Surprised nobody specified a default value for the INI read.
2. If the key is not found or an error, most do not send a message on the User Event or the Queue. What happens if the receiver is waiting for a message? Why not send a default value or a key not found message? Why not notify things downstream of the problem?

---

1) They did specify the default default string Value of Empty String and an empty string will be enqueued to the queue and passed as User Event Data as the Event fires.

2) Exactly!  That is a large part of the reason I would not Enqueue AND send the same info as Event User Data.  Decouple the Methods from the Data!  User Events do that well because they have 1-N synchronization.  Queues don't because they synchronize N-1.

[mcduff]

---

@JÞB wrote:

1) They did specify the default default string Value of Empty String and an empty string will be enqueued to the queue and passed as User Event Data as the Event fires.

---

True, but would be nice if there was an explicit default like default or not found etc.

Since the @OP is from JKI, I assume they are sending the message to a JKI State Machine construct, (maybe not the queue data but definitely the User Event data). An empty string brings one to an Idle State in the JKI State Machine, seems like they could add a "What to do if error state" for that message.

[JÞB]

---

@Hooovahh wrote:

---

@JÞB wrote:

Hooovahh,   did you right-click the merge errors and report all?  I think there is another glyph that would be visible if you did.  I could be wrong. 

But, I definitely advise adopting this new feature and would be disappointed if it was overlooked at GDevCon. 

---

It does not have merge errors.  I thought about it but I thought in cases you might get the same error reported twice due to the wiring.  But it probably is important for the User Event, and Queue to have unique errors tracked.  In practice it doesn't really matter because even one missing reference is bad and needs to be fixed, knowing you have two might not help debug it much.  But yeah what harm is it to just have it on?  Not much.

---

In practice... You would find the bugs BOTH of your development team members wrote and could assign Tracking for each.  Then the downstream bug author could get busy before they found out later the other guy's bug was masking their bug. 😉  it helps to turn it on- but I would run the Error chains through both Generate User Events and both Enqueue operations before the merge to avoid duplicate errors from the duplicated functions just as you said.

[Kevin_Price]

Had this tab queued up half the day before getting back to it.  Now that I've gone back and looked at some other posts, it appears to me that Hooovahh posted code that's functionally identical to mine but far less ugly.  I'd also give him the nod for wrapping everything up in an error case structure.  The post from Gregory is *almost* the same and looks even neater, but it differs just a bit in error precedence.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Interesting little topic.  Here's my contribution with a few additional comments below:

Additional comments:

5. Ouch, pretty ugly aesthetically!  Look at all those wires!  But functionally, I really don't want to remove any.  I've got specific reasons to want all of them.

6. General principle: upstream errors propagate to nullify *relevant* downstream actions, but not necessarily *all* downstream actions.  So an error reading the 1st value does not propagate to prevent an attempt to read the 2nd.  But an error reading either *does* propagate to prevent signaling that particular one via queue or event.

7. General principle: all error outs get collected and merged, with careful attention to sequence / precedence of errors.  (This is my starting point in real-life code too.  By default, all subvi "error outs" are accounted for in this vi's "error out" -- unless I make an explicit decision that specific ones can or should be ignored.)

8. General principle: leave supplied code pretty much in-place.  Make no additions unless necessary (such as Merge Errors).

-Kevin P

[JÞB]

Kevin, 

That is darn sneaky depending on the dataflow of the file refnum to enforce execution order of the enqueue and generate user event operations.   I had to look 3 times to see it.

[paul_a_cardinale]

Peeves:

1. Not cleaning up code.
2. Bad icons (like your original)
3. Hackery
4. Rube-Goldbergism
5. Schizophrenic code

Enforcements:

None.  Even before I retired, my cow-orkers often ignored my admonishments and advice; and there was nothing I could do about it.

[Kevin_Price]

Jay,

Confession: it wasn't meant to be a clever trick, it just sorta happened when I mentally "unrolled" the implied loop of "read-send-send / read-send-send".

Overall, I liked the approaches that repackaged this stuff into an actual loop, but none of them did the error propagation / precedence in quite the same way that I would want.  Here's how error propagation would look in *my* loop version:

-Kevin P

[Gregory]

---

@Kevin_Price wrote:

Overall, I liked the approaches that repackaged this stuff into an actual loop, but none of them did the error propagation / precedence in quite the same way that I would want.

---

The first INI read is supposed to use polymorphic VI with "string" selected, and the second is supposed to use the string VI directly. Just kidding, I assumed part of the experiment was to see how many people would change those to be the same VI or not.

[JÞB]

---

@Kevin_Price wrote:

Jay,

Confession: it wasn't meant to be a clever trick, it just sorta happened when I mentally "unrolled" the implied loop of "read-send-send / read-send-send".

Overall, I liked the approaches that repackaged this stuff into an actual loop, but none of them did the error propagation / precedence in quite the same way that I would want.  Here's how error propagation would look in *my* loop version:

-Kevin P

---

Overall, I would make the following changes to Kevin's code, If I didn't reject the silly construction for reasons previously stated. 

• Place the Error wire into the loop on a SR (to propagate upstream errors if Key[] is empty
• Place the config file refnum on a SR for the same reason.
• Branch the Error wire into the loop into three paths immediately at the Left SR inside node.
• Merge all three errors with a report all errors option
• Terminate the loop on Merged Errors = TRUE
• WIRE the Error SR out from the loop directly to Close Configuration File.
• Remove the case structure it's redundant for all Error consumers in this vi EXCEPT for close configuration file which will attempt to close the file anyway and report the upstream error if one existed. By internally passing a No Error into the File Close and merging errors (report first error option.) 

And yes, if you merge copies of the same error ( reporting all errors) you only get one instance of the error because <Status,Code,Source> is found already and not added to the output again.

[drjdpowell]

Don't think anyone has shown this option before:

Given the lack of specs, this is as likely to be the right error-handling strategy, and comes up often for me.  It's a "Notification Service" pattern, where the Service has no reponsible for the validity of the communication references to its Clients, but IS responsible for always sending something (like a default or sentinal value). 

In actual code, it would look more like this (using Messenger Library):