Error Ring Error in

[wiebe@CARYA]

It would help if the Error Ring had an error in.

Now we always have to use a merge error (A).

This does hurt performance as well (B), as Error Cluster From Error code is always called (and isn't lightweight).

With an error in, no more merge errors (C)!

And performance gain (D) as a bonus.

Guess this input is deliberately not there? Can't wait to hear the arguments against it...

[AristosQueue (NI)]

[[ AQ takes off his "NI LV R&D" hat, puts on his "G  Programmer user" hat.]]

For me personally, I'd oppose this idea. I didn't raise these objections earlier because it may be somewhat unique to how I use the ring... there are two things that would still make me put a case structure down, even if a Bool and/or error input terminal existed. Do any of you share these?

1. The code itself often needs to do stuff on an error. Sure, there's the system/resource things like rollback some database attempt; back out earlier scripting if later scripting failed; free allocated refnums; put hardware in safe state. But far more common, in pure dataflow code, during debugging, it's not uncommon for me to want to put a breakpoint in when the error occurs. If I haven't put a case structure around the error ring, I have to drop a conditional probe in order to get the breakpoint to only happen on an error. To me, that's not as nice as just putting a breakpoint on the error ring, which thus only executes when the error occurs.
2. There's almost always error ring parameters. I don't have parameters in library code that I expect to be on LV real-time or FPGA where strings are jittery (RT) or verboten (FPGA). But, more often than not, I don't just want to return an error code. I want to return info about the error. And that generally requires taking parameters from the function space and often massaging them into some sort of readable format. That massage code goes inside the case structure with the error ring so it only executes if I'm going to report an error.

Having a conditional terminal of any sort -- whether a boolean to skip or an error cluster to avoid the merge -- still wouldn't save me from needing a case structure around these nodes a large portion of the time.

[wiebe@CARYA]

1) I don't use breakpoints that much at all. I mostly use probes.

2) I tend to be lazy and let the error ring do all the formatting. Except an occasionally enum\format into string...

Those would be corner cases to me. The idea doesn't prevent doing that.

[AristosQueue (NI)]

Like I said, they're my personal reasons for not feeling urgency on this, which is why I left them out of the official conversation when discussing this idea's closure. But I figured I'd mention them after the fact as they're somewhat relevant to the node's design.

[Hooovahh]

My workflow isn't the same as AQ's.  Here is one example I just pulled from a device library I wrote.  It uses Modbus which will return some data and an error.  If there is no data it may not generate an error and so extra checks need to be in place to check for the absence of data and merge an error ring if no error has been generated upstream.  Similarity I've done things like perform a CRC check on the returned data and generate an error if the CRC fails, or if the header information in the response wasn't what I expected to also generate an error.  These extra checks are obviously custom, but also will mean a case structure is still there which means I can still put a breakpoint in the case structure to stop on one of these things being wrong.

[AristosQueue (NI)]

Hooovahh: that's exactly a situation where I likely would have code to harvest info from the "modbus reference" or its owning class to get some sort of ID out that I could attach to the error. Unless this is jitter-safe RT code or FPGA.

[Hooovahh]

@AQ Yup totally agree and my not very descriptive Error Ring can be improved and in many places is.  I usually wrap the Write and Read Response into a single function so that the error ring can have an input that is the last request which was attempted, before the read returned an error from a failed CRC, or timeout, or whatever.  My example here was just to illustrate that your breakpoint will likely still work as you would normally if an Upstream Error input was added to the Error Ring.  I think I'm a fan of the idea, but as I mentioned earlier maybe forcing the developer to think about it is fine too.

[drjdpowell]

I tried using this error ring thing and immediately hit the same problem of a lack of an error input.  This extra effort to do standard error chaining will lead to the default to be to drop the incoming error, regardless of what it is best to do in the specific case.  This would lead to major problems with debugging, where the most-upstream error is the most important to be award off.

BTW, I didn't really understand the relevance of the conversation about wrapping things in a case structure.   Of course there is always a case structure.