Error to Boolean - Available. . Why not for Integer and String?

[P@Anand]

Connecting the error cluster to boolean inputs is implemented and its a very good feature. The same why not implemented for the integer and the string data types present in the error cluster. There are several instances where this will be handy to use (Error handling - every project has this) so it would be very good if this is implemented. This can be implemented with certain restrictions as done for booleans.

[labview4steve]

I agrre, this should be a no brainer... With the new error and boolean comparison LabVIEW is training us to think in terms parts of the errror cluster being equalt to something, so if we can ask if the error is TRUE or False, why can't we ask if the error is a particular TYPE of ERROR  (or CODE) or STRING etc..

If you can compare any part of the cluster then you should be able to compare any other element that is part of that cluster so long as the TYPE is the same

[Ironman99]

Kudos!

And a further step could be...

         and      

may be configurable via right click on the Case selector.

Cheers

[P@Anand]

Good one. This could be made configurable right clicking the case seletor.

[AristosQueue (NI)]

Merely because something is well defined is not a good reason to break type safety. You're not going to win my vote for this one. If you think of the error object as a whole, then asking whether it is an error or not is meaningful, but asking whether it is equal to a string is not meaningful. Asking whether it is equal to a Boolean is not meaningful -- it is never equal to a Boolean. One of its fields, yes, but not the error cluster as a whole.

(And I'm talking about the original idea, not Ironman99's extension, which is a wholly separate idea that I'm fairly certain is covered elsewhere in the Idea Exchange.)

[P@Anand]

"Asking whether it is equal to a Boolean is not meaningful -- it is never equal to a Boolean"

I don't think I have posted anything like that, ofcourse its already available in 2011 - You can wire up the error cluster to gates and perform operations.

If you were talking about the integer type  - why not I had many case where I need to check the error code and for me I feel its meaningful.

Thanks

[AristosQueue (NI)]

You can wire to the Boolean logic primitives (And, Or, Not, etc) but you get a broken wire if you try to wire to Equals.

[P@Anand]

Yes I agree comparing boolean and a boolean doesn't make any sense but comparing an integer and an integer make sense to me and in many cases we do that.

[AristosQueue (NI)]

Comparing a Boolean and a Boolean does indeed make sense... they're either both true or their both false or they're not equal. It's no different from comparing two integers. What doesn't make sense is comparing an integer and an entire record of things, only one of which is an integer.

The error code cluster is the same situation. Value wise, it is never equal. And while we could weaken the type safety to allow this, each reduction of the type safety makes it more ambiguous as to whether that was intended or accidental wiring that LV is just interpreting as valid.

The hole we cut for the error code cluster attaching to the Boolean functions was deliberately narrow. We did not make the error code cluster coerce to a Boolean type. We overloaded the specific functions to have meaningful definition for the error code cluster in a very limited case where the ease of use trumped the type safety because the way those nodes are used are very specific with the error code cluster. But Equals is a much more generic operation, and I would not support weakening the type safety here.

Again, there's no technical reason we could not do this. There are merely opinions about why we should not do this. This happens to be my opinion, and it is one that is consistent with the rest of the design philosophy of LabVIEW that keeps the language approachable for new users and maximizes readability of diagrams written by two different advanced users.