need suggestion on error treating strategy

[MaGH]

I tried to construt a projec by LabVIEW. It consists of ActiveX controls, Signal Acquiring control, Signal Analysis, etc. And I architecture it with state machine. Synchoronization technique was introduced into the project to sychronize the UI Response and corresponding Background Operations, or to protect the Critical Section shared by some operations. In the end it run.

But something I haven't realized. That's the exception treating mechanism. How should I organize the error treating in a 'big' project? Something  like the exception-catch-throw mechanism, or anything else?

Till now, what I hnew about the error treating in LabVIEW is like 'combining error'.

Any  ideas and demos are appreciated!

And Thanx ahead.

Edward

[Dynamik]

Hi Edward,

This question doesn't get asked enough!

Here's a few Error-related ideas, though not really part of a formal exception-handling methodology.

- Implement your own Error-codes between 5000 and 99999.  This might allow for context-specific error handling in the spirit of "catch-throw".

- Write an event-logger to capture-to-disk program-events - including Fatal errors. (I've only done this a couple times.)

- If you want to present error information to the user, without having to pause/wait for a user-dialog, use a "splash" panel - a VI which pops to the forground and shows the error, but doesn't stop execution waiting for user acknowledgement.

- Check for errors frequently (always), beware that native functions and sub-VIs can handle existing errors in undesireable ways.  Some functions will execute even if there's already an error wired in, and may REPLACE the original error with a new error if the function fails.  This can be very misleading when debugging.  Other functions will NOT execute if there's an error wired in - even if you want them to.  It's common to Not wire the error-cluster to Task&Refnum Close functions (using some other data dependency to determine proper execution order.)

- You can use the error-cluster to capture/carry less-critical informational strings of your own ( just don't set status true! )

Great question! 

Message Edited by Dynamik on 03-08-2006 02:02 AM

[MaGH]

HI, Dynamik,

Thanx for your great ideas. But I'm not sure about something.

1, "Write an event-logger to capture-to-disk program-events "

Does it mean I should register error event to treat errors? To synchronize the error treating, with 'notifier' or 'queue' ? 

 Before LabVIEW, my tool is Visual C++. And some mechanics/methodology  impact on my thoughts. Maybe I was being trapped!   So, I'm not sure that whether the error treatment be dealed serially or parallel?

2, "Check for errors frequently (always), beware that native functions and sub-VIs can handle existing errors in undesireable ways.  Some functions will execute even if there's already an error wired in, and may REPLACE the original error with a new error if the function fails.  This can be very misleading when debugging.  Other functions will NOT execute if there's an error wired in - even if you want them to.  It's common to Not wire the error-cluster to Task&Refnum Close functions (using some other data dependency to determine proper execution order.)"

How to 'Check for Errors' ? Wire all error out serially or combine them? Sorry for my not sure about it.

If any demo is available , that'll be wonderful! The examples of LabVIEW doesn't involved anything on it.

Thank you, Dynamik, again. Great idea you gave me!

[Odd_Modem]

Error out serially is the normal way in LabVIEW. Error Combine indicates that you are multi-threaded. Sometimes, I use Error Erase because it makes sense when you look at the diagram. So, if you have a number of threads that run in parallel, you can combine the error in the end, when the threads return to the caller, to see if there was an error. If you want all the parallel threads to respond to the first error, you have to write that into the program as a feature. The error cluster should be used. The response to an error (the clean-up) should be documented. In LabVIEW, the response to errors, for built-in functions, is documented in the help files.

[Dynamik]

Hi Edward,

Sorry i ignored this for so long.  It seems like Odd Modem better understood your question.

> Does it mean I should register error event to treat errors? To synchronize the error treating, with 'notifier' or 'queue'

No, "event" was a [my] poor choice of words.  I only meant that having/using a log to dump information about thing's happening in a "'big' project", might be convenient for debugging.  If the "'big' project" terminates abnormally, a disk "error-log" could be very valuable.  It would be up to you to create such a log, and you would choose when to write to it.

> If any demo is available ...

Demos for how to handle errors?  Don't know of any.

Cheers

[MaGH]

Thanks you, Odd , Dynamik.

Dynamik, Your log approach is really a good idea to fix the bugs. This will help me greatly from now on!

Odd,  You gave me a clear idea of serial/paralle error treatment.

Thanx again.

[becktho]

Hi

Have a look at the Starware thread in the Breakpoint board. There I posted a log-library, which I use to log a lot in my programs.

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=1784

Just have a look at it (and maybe give some comments ;)).

Thomas

[Dynamik]

Hi becktho,  tried to check-out your util...

LV 7.1 here!

[becktho]

Try this one:

[Dynamik]

Hi Thomas,

Very interesting! This would have been a great tool for a recent forum visitor who had an intermittent crash.

I have a couple comments-not to be taken as criticisms - simply observations

I was surprised to see the LV2 global! (?)  I think several of the logging VIs (one for each Data-type) might be rolled into one by using a variant as input.  The only other comment is that log entries might have a timestamp(?) 

But this is just being picky.  Nice approach!  Your use of the queue to port messages to the File handling was really clever/excellent.  I'll remember this.