Improve error handler by including an object

[Ironman_]

The error cluster is obsolete, it's time to move on. It's 2018 we need a more flexible error output.

it's deeply hard-coded into LV.

The most hard-coded thing that is impossible to remove is that it's used as a way to force sequential instructions (error in -> error out are many times the only connectors).

The problem is that

• the error codes are limited
• dont scale.
• cant embed additional object into it.

I can't use the full range of I32 as error code.

If I use error code 6400, it will clash into yours 6400 custom code.

I need a way to say : this is the error code of MyModule/Actor/class/LVLIB, that I need to "namespace" error codes

I need an additional object into error cluster, so I can carry more info.

So pls NI, empower error cluster with additional field: "meta error object", that we can derive/extend and use.

[wiebe@CARYA]

Only one thing stopping this: existing code. Note that the error cluster is not a type def. So there is no easy\reliable\convenient way to transform old code.

[crossrulz]

It would be such a huge effort just to update their own code and drivers that NI did not even try it with NXG, which would be the time to make this update.  There are some functions in NXG which are a compromise.

[AristosQueue (NI)]

A change similar to this request is already in progress in LabVIEW NXG. I've been smuggling the change in over the last couple years. I hope to have the final pieces in within a couple years.

The LabVIEW 20xx platform will not be changing. Having said that, you already can append information to the error being returned. Use the "Error Ring" or the "Error Cluster From Error Code VI" and you can embed all the meta data you want.

[AristosQueue (NI)]

PS: Error codes aren't going anywhere. Strings are not supported [nor can they be really] on the FPGA target, and strings are sources of jitter on the real-time targets. The use of error codes is a quite deliberate choice for the G language to be able to support those targets. When we compile the error cluster on FPGA, the string field is left out; on RT, it is often left blank. In those cases, the code carries all the error information. Also, the error codes allow us to interop across human languages -- error code 7 can be displayed in English, Chinese, or whatever. If we start returning the actual strings as errors, that doesn't work out.

But just because they aren't going away doesn't mean they can't be made more flexible. 🙂

[pawhan11]

For Windows I use error string to store my error class that has more fields and methods that fit my needs. 

For RT/FPGA I don't thnik there is alternative without having performance problems.

[Darren]

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