How do you typically set the values of an error cluster?

[Aristos Queue]

This thread is about generation of errors. Please do not tangent off into handling of errors, except insofar as generating one error to replace one from upstream is a form of handling. I'm asking this question partially as LV R&D, with an eye to the future, but more as a CLA user with an eye to writing code that is good style.

In the question about dropping warnings, this is the type of programming that I mean:

[bmoyer]

When a subVI needs to create an error to return to caller, how do you typically set the values of the error cluster (you may check multiple)?

Other: I typically I use the Build Error Cluster__ogtk.vi along with the Error Codes Ring constant__ogtk.vi.

[mje]

I always use the Error Cluster From Error Code.vi that ships with LabVIEW. Doh, never realized it was a poll. Ignore my useless comment.

[crelf]

I typically I use the... Error Codes Ring constant__ogtk.vi.

Me too - it's invaluable. Much easier than trying to hunt down an appropriate error code, and your BDs are more readable (I've seen people create their own 5000 series error codes rather than looking for an existing code).

[Antoine Chalons]

When a subVI needs to create an error to return to caller, how do you typically set the values of the error cluster (you may check multiple)?

Other: I typically I use the Build Error Cluster__ogtk.vi along with the Error Codes Ring constant__ogtk.vi.

Same for me.

[ShaunR]

I think warnings are a double edged sword. For example. How many people turn off warnings on the LabVIEW error dialogue unless you are optimising? I prefer prioritised errors since the default Labview handling for errors will pop-up dialogues which then forces you to consider the seriousness of the error. It also enables you to do things like graceful degradation. Warnings, however, don't really give you much apart from the headache of documentation explaining what it means..

Edited March 17, 2011 by ShaunR

[soupy]

We use errors to indicate a task failure, so all subsequent operations are not performed. Because of this, we NEVER overwrite an error or change its code because it makes it hard to determine the origin of the error. We use warnings to alert the user of non-critical things (i.e. "Your DAQ card will require calibration in 30 days, contact QA for a replacement"). If an error is generated after a warning, the warning is overwritten.

To handle all of this logic, we use this VI to create an error:

It has the features:

• can create error or warning
• code is an enum (similar to ogtk enum)
• created errors will overwrite warnings
• created error will not overwrite previous error
• created warning will not overwrite previous warning
• call chain is included in error source
• optional custom text can be pre-pended to source

typically we create a 42:generic error and just describe it with custom text or error details (i.e. Excel tab "foo" is not found)

Note: our software is used internally, so we are always a phone call away to describe what an error message means so messages can be a little more cryptic. if you are producing software for external release, you will have to generate messages that are a little more user-friendly

Edited March 17, 2011 by bazookazuz

[jdunham]

I find it hard to believe that anyone claims never to overwrite errors. I'm not sure how you detect the presence or absence of a file without trying to open it, getting error 7 and then filtering it. I suppose you could list the containing folder, but that seems a lot harder. There's nothing wrong with the former method of generating an error and then clearing it.

In addition there are plenty of routines that can throw a User Cancel error as a normal part of user interaction. So maybe the clarification is that you should never overwrite an unexpected error.

We have a Filter Error function that is useful. I've never figured out why this hasn't been added to vi.lib. The clear errors function clears all errors, but you should only be clearing expected ones!

As far as generating errors, we have one that dumps the calling path into the error source, which I'm sure is pretty common. What it also does is that you can wire anything into it, and it uses the OpenG Lvdata tools to serialize the arbitrary data to a string, and then you can get a data dump in the error message.