connection id when fail to open connection

[Jim12345678]

When trying to open a tcp connection using the TCP Open Connection function, is there a defined/consistent connection ID refnum generated if the connection fails (e.g. connection ID = 0)? The help does not describe the value should the connection fail. 

[Mancho00]

---

@Jim12345678 wrote:

When trying to open a tcp connection using the TCP Open Connection function, is there a defined/consistent connection ID refnum generated if the connection fails (e.g. connection ID = 0)? The help does not describe the value should the connection fail. 

---

I'm not aware that there is any specific value, but you should get an error from the function, also if you check the connectionID with "Not a Number/Path/Refnum?", it should return true.

[Jim12345678]

Thanks.

I'm hoping to avoid having to parse the error code and subsequently create another variable that tells me if the connection is valid.  If the connection ID defaulted to a known value in the event of a failure it would serve both purposes.

[rolfk · Accepted solution]

When the Open Connection fails for whatever reason the returned connection id is an invalid refnum. I’s likely the canonical Not A Refnum value BUT you should not infer from the refnum value if it is valid or not based on comparing it with the Not A Refnum value. while the Not A Refnum is always an invalid refnum the opposite is not true. You can not take a refnum and assume that it is valid because it is not equal to Not A Refnum. The Is Not A Refnum/Path/Number function is the right thing to use for determining if a refnum is not valid/open.

That all said trying to infer the success of Open Connection from checking if the refnum is valid, while possible, sounds to me a very roundabout way. Using the actual error output is the normal and recommended way, and also allows you to do possibly specific error handling depending on the error code. In any case you won’t loose any information: if the function returns an error it was not successful and the returned refnum is invalid. The opposite is principially true as well although not how LabVIEW normally operates.

And you don’t have to necessarily evaluate the error code. If the boolean in the error out is true there WAS an error and you are done if you do not want to know in more detail what went wrong.

[Jim12345678]

Thanks.

My interpretation of what has been written with regard to this question is that the "not a refnum" function is not to be trusted either due to race conditions or because you cannot assume that a refnum is value because it does not equal not a refnum (I admit that this latter reason is a bit baffling since I would think you either are or are not a refnum.  I suppose you could have once been a valid refnum but are no longer).

[Mancho00]

---

@Jim12345678 wrote:

Thanks.

I suppose you could have once been a valid refnum but are no longer).

---

Here one way to look at it (for illustration purposes only)

[johntrich1971]

---

@Mancho00 wrote:

---

@Jim12345678 wrote:

Thanks.

I suppose you could have once been a valid refnum but are no longer).

---

Here one way to look at it (for illustration purposes only)

---

Your top one is not guaranteed to be False either. Since there are no dependencies either the close connection or the not a refnum could execute first.