Non-unique custom error codes

[tadders]

Hi all,

I seem to be getting multiple error code matches from my custom error rings when passed to General Error Handler.

I have multiple custom error code files located in <install path>/user.lib/errors that share error code values e.g. File 1.txt for one application contains:

<nierror code="5007">
Steady Aerodynamic Coefficients (dCmCofG_da) suggests an unstable model
</nierror>

File 2.txt for a completely different application contains:

<nierror code="5007">
Invalid modulation [ AM | CW | FM | LSN | USB ]
</nierror>

When the error occurs I use an error ring constant applicable for the application.

When triggeredtThe resulting output is:

Warning 5007 occurred at MRET Model.lvclass:Read Steady Aerodynamic Coefficients.vi

Possible reason(s):

Steady Aerodynamic Coefficients (dCmCofG_da) suggests an unstable model
=========================
Invalid modulation [ AM | CW | FM | LSN | USB ]

Should the error code values be unique across the custom error files?

Thx

Tadders

[Bob_Schor]

They are available for "customization" as the User wants.  My approach is to assign a unique code for each "identifiable" error to aid me (and the users of my routines) in understanding what the error represents, but there are no "rules" for this.

Bob Schor

[tadders]

Hi Bob,

Thanks for your reply - that is how I use custom error codes!

My problem is if I have multiple error code files, I get a message which is derived from both.

Phill

[Bob_Schor]

Hmm -- I've never used "multiple Error Code files" -- I tend to have the Error Code files local to the Project where the Errors are being "trapped".

Bob Schor

[tadders]

Hi Bob,

Ah, we package them for installation into user.lib/errors

Phill

[Bob_Schor]

Aha, I understand the problem.  As my mom used to say, "Don't Do That!".  [I'm only kidding ...].

Bob Schor

[Konan__]

We need a "namespaced" error code so that your library can have error 5007, AND another library can throw the same error, BUT you can EASILY distinguish.

Obviously in half 2019 it's a too advanced and complicated feature for NI to implement.

I hope they will implement it in Labviw NXG 72.2 around the year 2052 when my personal time-space machine devie should be ready for the mass production.

Meantime, remember to support NI with regular LV subcription

Cheers.