Allow References to be Wired into Case Selectors to Check for Validity

[JackDunaway]

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

[muks]

I like the idea .

[PJM_Labview]

This is an interesting idea that would never have occured to me. The more I think about it the more I like it. So Kudo.

[AristosQueue (NI)]

I've never liked "check for valid reference"  code, and I'm afraid one of the problems with that type of code might be made worse with this otherwise helpful feature.

Consider: 

A reference can be used in parallel in many sections of the same VI or in many different VIs. Suppose that in Branch A you have a "Not a Refnum?" node followed by some subVIs that do some work with that reference. In Branch B, you have a Close Reference. A user may think "I test for the validity of this refnum and then, because it is valid, I do some other things with it." What actually can happen is the "Not A Refnum" node executes and returns false, then the Close Reference node runs, and then the code that should only happen with a valid refnum runs -- although the refnum is now invalid. 

This is an easy mistake to make today, but when I have had to explain it to people, they generally see what's happening because there are two distinct nodes and they can imagine them running interleaved. With the case structure, there might be a sense that the case structure is still running and somehow has a lock on the refnum to keep it from going invalid. I don't think it would be possible to code such a lock, and I'm pretty sure any attempt to do so would backfire on someone (having to move calls to Close Reference out of the case structure because it is locked, creating artificial long-term locks of reference types, nested case structures all locking the same refnum... the bookkeeping could definitely be done, but it gets messy).

Rather than use of "Not a Refnum?", why don't you just use the refnum? In the example picture above, there is no reason for the use of Not A Refnum. The Notifier primitive will immediately return an error if the refnum is invalid, doing exactly the same work that the Not A Refnum node would do, and that error cluster can be wired to a case structure. There are only two cases I know of where the Not A Refnum prim is the right choice: when writing some very specific clean-up code for mimicking a circular graph structure and when writing a custom probe. I'm not saying there aren't others, but I am saying that this ought to be sufficiently rare that I'm not sure its worth creating the special case structure to handle it, especially if that special case structure adds any confusion to understanding parallel timing.

or

Message Edited by Aristos Queue on 11-23-2009 09:14 AM

[tst]

Checking for the validity of a reference is useful if the reference can go bad and you want to silently correct the issue by obtaining a new reference.

[AristosQueue (NI)]

> Checking for the validity of a reference is useful if the reference can go bad

> and you want to silently correct the issue by obtaining a new reference.

True. I did say I suspect there are other valid use cases out there -- those were the only two I could think of off the top of my head. Do the use cases you can think of overcome my concerns about the parallelism and the excessive work done by nodes to check the refnum?

[tst]

No, I agree that without a mutex you can't be sure that you still have the reference and that most times you can let the error wire take care of not running the code. In my code, I don't remember having cases like what appears in the original post, but I occasionally have cases where the GOOD case is empty (passing the reference) and the BAD case has handling code.

Two additional points:

1. Error wires are problematic because you can't tell where the error came from. To know if the error is related directly to the code, you have to wrap the code in error case structures, which can become a bit ugly if you have a few levels.

2. Not all references can be checked using the NaR primitive (ActiveX refs, for instance, can point to an external source, so you have to verify that the source is still valid), so even if this is implemented, there are still cases which would require more code. That said, it's still more readable than the current implementation, which is why I voted for it.

[JÞB]

I think its a pretty good expansion for the case structure and would be especially useful for vi server refnums, file paths and file refnums. 

[WG-]

It is nice but... isn't it applicable to all comparison items... such as

- Is empty string?

- Is decimal digit?

- Is printable?

- Is whitespace?

- Is empty array?

- Is not a number?

I think we should stick with the old method.

[AristosQueue (NI)]

Just a thought... adding this "check if refnum valid" behavior to all refnums for the Case Structure would get in the way of the Case Structure having a "select based on class of refnum" behavior, which is also on the Idea Exchange here. Which feature would people prefer? I recognize that this one has more Kudos, but this one has a decent existing workaround. The other idea does not.

[tst]

If the two are mutually exclusive then the other idea is definitely more valuable.