error output instead of error code output

[X.]

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

[AristosQueue (NI)]

It's a good suggestion, but in the meantime, you do know about Error Cluster From Error Code.vi, right?

[X.]

Sure, but it is bulky. The guy who worked on the Analysis VIs I used as an example apparently did not, BTW 🙂 [or they were developed before that VI was released].

[AristosQueue (NI)]

Strike my previous comment about this being a good suggestion. I thought you just wanted to return error clusters instead of error codes and have the call chain lead to the Kaiser VI. You actually want to output string messages. Ah. No. That's a bad idea. It would make error reporting on FPGA impossible and on RT it would introduce jitter. It would not be after-the-fact localizable (i.e., the result returned on a French system could not be interpreted for an English user, or a Japanese user, etc).

Any individual error cluster does have the ability to attach additional information to that stored in the error code database or to override the error code database entirely, but it does so with the penalties noted above. Thus VIs that are core parts of LabVIEW avoid doing this unless backed into a corner (i.e., translation of a .NET exception into an error code cluster does not have a unique code for all possible .NET exceptions).

> [or they were developed before that VI was released].

Likely this.

[AristosQueue (NI)]

By the way... bulky? It is barely doing more than the Analysis library VI that you posted, and it addresses a couple of bugs that I see in the Analysis VI (propagation of upstream warnings, for example). About the only thing extra it does, on desktop, is fish out the VI Title so that the localized name of the VI is displayed instead of just the file names that you get from the Call Chain.

[X.]

---

I thought you just wanted to return error clusters instead of error codes and have the call chain lead to the Kaiser VI.

---

Yes, that's obviously what I suggested. Not sure how you got the "String Message" thing from...

The Error Cluster From Error Code.vi is unwieldy because it does not provide an easy way to get the call chain (which is probably why the AAL Error Information.vi was introduced):

=========>

Unless I am missing something, there is no way without some significant code, to figure out the source of the error and as I remembered, the VI does actually not return the error message (the cause of the error, see my original illustration) either...

PS: And stop saying my ideas are bad! 🙂 It influences PC/easily-influenced/authority-respecting people out there who won't dare vote for the idea just because of that.

[AristosQueue (NI)]

> into error cluster outputs with proper messages.

I took this to mean you wanted messages to be in the error code cluster instead of the error codes. Kudos restored.

> PS: And stop saying my ideas are bad! 🙂 It influences PC/easily-influenced/

> authority-respecting people out there who won't dare vote for the idea just because of that.

Hah. I take you for one of the high-authority folks that people respect. Your commentary is generally of a very good quality, and you're good at rallying forces. 🙂

[Darren]

Available in LabVIEW NXG. VIs that output error codes have been refactored in LabVIEW NXG to output error clusters instead.