Close reference - Option for warning instead of error

[matt.baker]

The close reference node returns errors for invalid references (1026, 1055 etc.). The majority of the time, I don't really care. I then have to manually filter out this error on that particular node.

Could we have a bollean option to generate warnings on invalid VI refs instead? Similar to the following:

[wiebe@CARYA]

Just don't wire it?

[matt.baker]

How do you mean?

In the example below the Connector pane's Controls array returns invlaid refs if not connected to anything (as expected). I like to keep the error flowing.

[wiebe@CARYA]

So you want the error to flow, but don't want the error to flow... Not sure how much of a use case that is...

[AristosQueue (NI)]

[Speaking as a member of LV R&D] I'm open to counterarguments, but my first instinct is "this is not a good idea."

What you describe is a fairly dangerous use case: yes, there are some applications wherein multiple places in the code can safely throw away the same refnum, but those apps are a slim minority. In the vast majority of cases, if a refnum is disposed already, something very bad is happening in the code. I say that with 18 years being on the receiving end of "it doesn't work, LV must be broken" bug reports -- refnums being abused in parallel code is one of the biggest sources of user errors and so require the biggest handrails. Advanced users who really know what they're doing can operate outside the standard patterns, but often the problems aren't obvious to novice and intermediate programmers.

Given that, providing an easy way to knock out an error seems likely to me to be used by people to suppress an error without taking the time to understand that they have a significant bug that goes far beyond the "already disposed" error. Sure, during development, it happens that the "already disposed" is only cropping up at Close Reference, but if it is a timing problem, that error might occur anywhere else with just a bit of a timing shift. Consider: What makes Close Reference so special that it should have the suppression option as opposed  to any other Invoke or Property node? I don't think there's any significant specialness in those apps where parallel dispose is possible.

It's easy to wrap Close Reference in a subVI that demotes the particular error to a warning if this use case is common for you. Because there's an easy workaround and because adding the terminal would send the wrong message about the right way to use refnum APIs, I don't think it should be encouraged as an intended pattern by adding a terminal to the API. 

Having said all that... I'm not going to ask the team to close this idea immediately. Let's leave it open and see what kudos it garners and what other users think.

[matt.baker]

wiebe@CARYA:

I see what you mean. Although I think the layout just seems neater with the wires going through.

That being said, I'm coming around to the reason for generating the error.

My original reasoning was that closing an invalid/already closed reference has no effect on the outcome so it should be a warning by default, but, based on what AristosQueue said, I can see the benefits of raising an error.

AristosQueue:

Many thanks for the describing the reasoning behind the need for an error. They're all valid points which, on reflection, I completely agree with.

As an aside, thinking further about the example I provided, I only needed to explicitly close the VI ref and not the others so it wouldn't have been an issue anyway in this instance as the other nodes would have generated valid errors if the refs provided were invalid/null.

[wiebe@CARYA]

There's a subtitle difference between your idea and AQ's remark why that's not a good idea.

In your example, you're getting null references, from the invalid connector pane controls. That's a slightly different situation then closing references that are already closed. When trying to close a reference that's already closed, you do want an error. When trying to close a null reference, you could argue that closing an object that is not a created object at all should not give an error.

So there might be some merit in not raising an error if a null reference is closed. That would a) allow you to flow the error through, and b) still raise an error if objects are closed twice. Probably still a bad idea in general, but in this situation it would make sense.

Wrapping the close in a SubVI only became easy with the event of malleable VI's. Before we had them, wrapping the close was a pain, as each base type needs it's own VI...

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.