Error Handling - Part I Meaningful error messages

[JackHamilton]

:!: Problem:

How to generate meaningful error messages and codes for an application. Without it being a pain.

Issues:

1. LabVIEW internal error messages are not germane to your application - only the programmer (may) understand them.

2. Too much work! There are hundreds of possible errors that an application can generate - and creating a special message for each is too much work!

3. I'm not gonna take the time to scatter hundreds to text boxes in my code - loading the application with a huge database of error messages.

4.I don't have the time to STOP coding to think about an error message - it interrupts my work. It needs to be fast & easy to use!

5.When you're done - how do you document those nifty error codes.

Error Re-coder

The error re-coder - reformats the low level LabVIEW error messages and codes - to a custom code for your application. It works by taking a input error cluster flagged TRUE - and using a strict type def enum as the control to reformat the input error message to the text string stored in the enum. It also uses the enum numeric value as the error count - output as the error code.

Using a Strict-type Def enum - allows you to

1. Reformat default LabVIEW error codes to have a custom meaningful message to your application.

2. Assign a custom error code.

The beauty is:

A. You can add custom error codes as you work - open the strict type def and Add another value.

B. Code is self documented - the Enum displays the error code and text.

C. When your project is done - you can dump the enum strings using property nodes and create an application error table!

The attachment is the error coder with an example wrapper VI. All you need do it change the Enum value text to your own special message.

This is the first part in an error handling methodlogy that I have been working on for the past years. I hope to share some other error handling routines later.

Written by Jack Hamilton

JH@Labuseful.com <mailto:JH@Labuseful.com>

www.Labuseful.com <http://www.Labuseful.com>

LabVIEW Tips, Tricks and Downloads

Download File:post-37-1096996400.zip

[didierj]

Do you also have it as LV 7.0 ?

Didier

[Albert-Jan Brouwer]

Jack,

Improved error handling is definately useful. But using error codes to specify what went wrong is somewhat limited. Oftentimes you would like to include runtime variables in the error. For example, when a function fails to open a file, including a path+filename as part of the error is helpful to the user. With error codes you are limited to generic error descriptions such as "could not open file" or "access denied".

This CAN be done at runtime by abusing the source field of the error cluster as a general purpose string. Resolve any error code to a string using the error code database and format any further explanation including runtime variables. Prepend that string to the source string of the error cluster. By marking such "explained" errors with a special error code, your error handler/logger/window can be signalled avoid further resolution and instead display the source string verbatim.

There are a couple of VI's in the "source/library/error handling" subdirectory of the LuaVIEW distribution that assist with doing so. The distribution is downloadable here: http://www.citengineering.com/LuaVIEW/download.html

The error handling VIs are self-contained (do not depend on Lua) and thus can be used with arbitrary LabVIEW code.

If you in addition wrap your LabVIEW code in Lua code, you can have an actual exception mechanism with all the corresponding advantages. For an explanation see: http://www.citengineering.com/luaview/manu...rror%20handling

---

Albert-Jan

[JackHamilton]

Albert,

That is very true. I am attempting to build a tutorial, one step at a time. Most applications don't employ sophistcated error handling at all.

That said I do pass the calling routine and sometimes error details & data in the error description I've used VI server to pass the calling path of the subVI - but in most cases this is useless to the user. (and sometimes me)

I rate error handling in code in 3 levels.

1. Code works! error reporting via application crashes.

2. Code reports errors - all of them.

3. Code employs methods to recover from error conditions - reports only those non-recoverable errors.

Micrsoft reports that in percentage of code, 50% of Office code is dedicated to error handling & reporting. I am including routines that deal with user interface errors. "Undo" and "Cancel" are really user input errors - but we have to write code to deal with them.

Also, I think it more helpful for programmers to understand the underlying madness and methods over simply installing and using some pre-built solutions.

The example code attached in LV7.0 version.

Download File:post-37-1097193017.zip

[Albert-Jan Brouwer]

That said I do pass the calling routine and sometimes error details & data in the error description I've used VI server to pass the calling path of the subVI - but in most cases this is useless to the user. (and sometimes me)

Yes. Particulary when the VI that threw the error has a large diagram, e.g. a state machine with many states or a driver with many action cases: with only a call chain you'll still be searching around. In such a case one should really append the state or action enum to the source string of any errors that occur.

Ideally errors should explain to the user what went wrong, where the error occurred, and what the consequences of the error were (e.g. the halting of subsystems). Where possible, suggesting a means of resolving the error is also useful. Of course, all that is a lot of work. But then, time invested in error handling tends to pay for itself later in terms of easier testing and deployment, and reduced support costs.

I rate error handling in code in 3 levels.

1. Code works! error reporting via application crashes.

2. Code reports errors - all of them.

3. Code employs methods to recover from error conditions - reports only those non-recoverable errors.

You might add:

4. Code limits the error effect scope by aborting only those subsystems dependent on the operation that failed.

Unfortunately, going from 2 to 3 or from 3 to 4 involves restructuring your program which makes the gradual extension of the error handling costly. When starting on a large application it is probably cheaper to opt for full-featured handling right away.

The example code attached in LV7.0 version.

I downloaded the archive but it won't unpack. Might the file be corrupted?

[JackHamilton]

Hmm it was the correct size but corrupted - the link is now revised to a new zip. This is a windows WinZip file.