Custom error handling - Can I pass a description?

[cbutcher]

Aiming to reduce the frequency with which I litter my code with comments like "#ErrorCode: Place an error here!", always intending to later update the Error Code file, then choose from an error ring rather than just a custom error with a number from the top of my head (in the user range), I'm looking at ways to build a library for simple error handling.

I've got something that works semi-reasonably, but since the errors aren't stored in a custom error file, the error indicators refuse to give me a description. Is there something I can do about this other than a) create a custom error file, or b) store the message in the 'source' string?

Below is an image of one of the VIs I've written. It passes errors to an Actor for logging and pushes an error onto the Error Out indicator - it is called indirectly by VIs in other places which ideally should just need a boolean (error or warning?) and an error code (I32 coercion from enum is the current plan). I also tried using the General Error Handler (with a bundle-by-name after to force the status flag) but this also doesn't add a description. The message is found in either case, but I can't get it to an indicator, only to my logger via the message I've set up. Should I be happy with this? I suppose often error indicators are not visible, either being hidden or in subVIs with closed FPs...

Edit: There should be a 'Equal to Zero?' check on the Code before execution, otherwise I get the source with a 0 code and warning...

[JÞB]

Create the custom error file then make sure to include it in you SCC and deployments

I've gotten into the habit of adding a ReadMe.txt in the SCC repository to reserve error code ranges by library. Then create 1 error file per project eg mycoolFoo_errors.txt the source should disambiguate any accidentally duplicated codes that refer to vis not in mycoolFoo.lvlib

[cbutcher]

Is the recommended method for using these in the development environment to just sym/hard link each error file into user.lib? (and then remove them after testing during deployment?)

I took a look back into VIPM's settings and see that I can set the file in 'Source File Settings' to be installed as a 'Custom Error' destination, which defaults to <LabVIEW>\project\errors\<category>\<package name> as far as I can see - I guess that this will solve any problems with deployment even without building an executable/application.

[paul_cardinale · Accepted solution]

Try these.

[cbutcher]

Aha! At first, I was disappointed by not being able to use your awesomely shaped icons, but then, googling for <append> tags, I learned how they should be used, and tried setting 'Append' to false. Now, it works beautifully!

The link I found useful was here: https://forums.ni.com/t5/LabVIEW/error-handling-basic/td-p/1050205

[JÞB]

---

@cbutcher wrote:

Aha! At first, I was disappointed by not being able to use your awesomely shaped icons, but then,

---

Oh then try to find out how to get those nasty coersion dots out of the way.:D. That was a unique use of the new (then) native recursion feature:)

If you actually find that post.  It's another one I failed to tag so, posting a Link= kudos

[paul_cardinale]

Are you looking for something like this?

(Note: To make this handy, put a launcher in the "...\National Instruments\LabVIEW 2016\project\" folder that calls "Find Coercion Dots.vi".)

[JÞB]

---

@paul_cardinale wrote:

Are you looking for something like this?

(Note: To make this handy, put a launcher in the "...\National Instruments\LabVIEW 2016\project\" folder that calls "Find Coercion Dots.vi".)

---

No Kudos for you today

This took me a while to find by digging though here

[paul_cardinale]

I interpreted "get those nasty coersion dots out of the way" to mean 'get rid of those nasty coercion dots'.  It never occurred to me that someone would want to move them around.

[JÞB]

---

@paul_cardinale wrote:

I interpreted "get those nasty coersion dots out of the way" to mean 'get rid of those nasty coercion dots'.  It never occurred to me that someone would want to move them around.

---

I don't recommend the vi