I can see your point. The reason I did it that way was to indicate to readers that the section was currently under dispute. I agree with you that the discussion would be better back here, but should we have any indication in the article that the user should check the discussion forum while an item is under dispute?

I totally agree. I will create a little template code that any editor can place at the beginning of the article to indicate this. i will add that to the style guide when i'm done. Thanks for the suggestion.

The context of your comments regarding Error Handling is continuously running applications. I would never knowingly include a One-Button, Two-Button or Three-Button Dialog in any application designed to run without user interaction for an extended period of time. More generally, I would not include the General Error Handler.vi and its 18 subVIs into such an application if the Error Code Database.vi alone was sufficient for my purposes. I'm interested in the "translation of error code cluster into human readable strings", but I found no discussion of how the "source string itself may include information to override or extend the database". While encoded information in the source string may be useful, formatting commands are probably not a big concern in error logs. Continuously running applications typically need a quick method for logging basic error information.

1) The "no error" string is not in the database. In fact, if you give the number zero to the database VI, you'll get back GPIB error zero. Yes, they used error code zero back in 1980 and we're stuck with it. The "not in database" string is also not returned by the database VI. If you want to differentiate "no error" from "not in database", calling the database VI won't cut it.
2) There is a range of error numbers that gets translated before being processed by the database primitive. Open up General Error Handler CORE.vi and look right before the call to the database. That handles some backward compatibility issues.
3) Look at the case structure that contains the call to the database function. You'll see the different options that we have for processing the source string (I'll describe those in a moment).
4) NI may at any time realize that it needs new error handling/translation facilities. For example, there's been talk of one group needing to provide error descriptions from another non-NI product, when that product returns error codes to LabVIEW or CVI. Those wouldn't be in the NI database. We'd probably do something like reserve some error range for them, and if the input code is in that range, then we'd call some other subVI to get the description, one that could read the other product's error code descriptions.

That last one probably won't happen until we get support for the tag since it would further expand the General Error Handler.vi (GEH) and we'd like to get the GEH footprint smaller if possible.

What's the tag? Oh, right... I said I'd further describe item #3.

Information about translating the error code can be embedded in the source string. The documentation on the other information that can be embedded in the error code source string is not documented officially.

There are two currently supported tags:

and


Do not be surprised if


gets added in the near future (see my post elsewhere on LAVA for a copy of my prototype of the revised of the General Error Handler.vi, usable in LV8.2).

The tag indicates that the data that follows the tag should trump any information in the error code database.
The tag indicates that the data that follows should be appended to the information in the error code database. An example is error code 7, file not found, can use used to indicate which file was not found.

Further, the strings that come back from the error code database may include formatting tags ( and ) that are stripped out when processed by the General Error Handler.vi.

The tag will indicate that the information that follows is a flattened LabVIEW Class of type "Error.lvclass". Again, see my post elsewhere (don't feel like looking it up right now).

I'll dispute your "Continuously running applications typically need a quick method for logging basic error information" comment. If you need a deterministic item to write down in the log file, write down just the error code. Don't handle strings -- they're unpredictable. Someone could put a manifesto in the error source. Or, use a queue to send the error cluster to a lower priority subVI that can write the information down more completely. Anytime you're not inside some absolute timing loop -- ie, if you have enough time to maintain the log file at all -- use GEH. Errors are an exceptional event. Typically, they occur only rarely, and you don't need high speed logging of errors.

I have to admit. I also use the Error Code Database.vi. I only use it inside my own custom error handler. A lot of us have created our own error handlers because the existing system sucks. It sounds like there is some work being done from NI to improve this. That's good news. Perhaps for the sake of the Wiki article, we should present traditional methods of error decoding. It seems like NI only recognizes uses of VI's that are visible from the palette. In other words, if NI decides to improve the error mechanism, they will only support migration of the GEH or SEH usage. I think we should not totally remove the description of using the Error Code Database.vi but move it to another page and reference it from the main error handling page. We should be presenting "best practices" in the main article pages.

Just trying to help out.

Using the General Error Handler.vi in continuously running applications does not represent "best practices" in my opinion. The target audience for an error log is typically not a general user. The Error Code Database.vi provides useful and sufficient information in this case. Simply logging the error code and subsequently looking up an explanation is no more informative and certainly less convenient.

I don't follow your argument against using it. If there is no error then there is not overhead. Calling the General Error Handler.vi with the "no dialog" option set will return all the required information. Are you concerned about execution speed in loops when errors are generated? If you have continuously generated errors then you need to decide what to do next. Keep logging the error and potentially filling up your hard drive or stop the app. I agree. This is why perhaps we need a dedicated article page on error logging and error handling techniques. I did not suggest this.

This is the discussion topic for the wiki article: Error handling

I could not agree with you more. You don't want to have extra code in the program when the program isn't any better from it. So dumping the errors to disk is common practise.

At CIT, the company where I work, we have a multitude of error routines. There are a couple of things you may want to do in response to an error:
1. show to the user (optionally from a separate error UI loop to prevent holding up the program)
2. store in in memory so that the errors can later be viewed by the user (an error log viewer)
3. store it to disk (and optionally have it loaded and viewed by the same viewer as of point 2)
4. send an email or SMS for it (with collection of multiple errors in a single message and retrying)

I think that there are two kinds of errors:
1. system/lib errors. These require to be able to respond to them, but only to selected ones. The error code is necesary to be able to discriminate between various errors. The programmer can do something specific for each error. Unknown errors just fall through and go up to the higher caller (it's a try-catch construction).
2. application errors. These don't require the possibility to discriminate by number, a message is telling much more than a fixed number here. I typically always use code 5000, but there are also many people that do use proper error codes here and add the codes to the database.

I always automatically add the time to the error when I create the error. Note that for various reasons it is possible that the moment the error is logged is much later than the moment it occurs.

Finally I have an Extend error message VI that allows me to add any text to the error. It is added in the correct <append> or <err> section. This is convenient to indicate details about how the error occured, because for example error 7 "File could not be found" does not tell which file is was.

Joris

Hey all - I've added a chunk of intro info to this page. I haven't uploaded the associated images yet, but they'll be up within a week.

Yes, yes, I know I've been slack on finishing my edits to this page, but they're coming soon - I promise