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

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

Not exactly... you could put the error ring inside a case structure.

This idea is essentially a duplicate of this one:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Error-Ring/idi-p/2351100/page/2#comments

[AristosQueue (NI)]

No arguments against. Just didn't include it in the original, and the case structure has sufficed, so no priority, especially given the annoyance of the mutation and save for previous code.

[wiebe@CARYA]

>This idea is essentially a duplicate of this one:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Error-Ring/idi-p/2351100/page/2#comments

That one is with Booleans (didn't find it when searching), it won't help with the merge errors.

If the XNode would accept both (maybe even at the same time?), that would be great! Then we can conditionally add it, but it won't previous existing errors.

[Darren]

National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.

[wiebe@CARYA]

That's unexpected.

The proposed solution of putting it in a case structure will clear warnings. The case in the XNode could prevent that. So to avoid automatic performance, clear wire flow and convenience, we need to wrap each and every error ring in a case structure, AND use a merge error.

I'm confused.

Not sure what the downside is of the proposed idea? (except "save to previous", which hopefully should not stop progress.)

[AristosQueue (NI)]

Darren was trying to state the workaround, not state a reason why this wasn't going to be done.

[wiebe@CARYA]

Declined: National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.

Sounded like it to me.

So what is the reason?

[TomOrr0W]

You mention putting the ring in a case structure clearing warnings.  How would that be?

If you are appending an error to the wire, the error will override the warning.  If you are appending a warning to the wire, the previous warning will take priority.  If the wire already has an error, the error case would be called and the previous error would pass through.  This would be the case regardless of whether you use a case structure, a select node, or your idea.

[wiebe@CARYA]

You're right. I was already caught up a bit on the conditional error ring idea:

Then the warning will be lost, even if the ring produces no error. Maybe in some corner cases it will still be an issue, but normally it won't.

The hole optimization problem is not really an issue altogether, as it will only save time when there error in is true. There's usually no need to optimize for exceptional (error) cases. It will help the flow and speed up development though.

[Hooovahh]

As much as I'd use this, I agree that leaving it up to the developer might be the best way to handle this.  Forcing them to add a merge error and then figure out what error should take priority is probably a good idea, rather than having a brainless developer (myself included) just wiring in errors instead of thinking about why and the consequences.