Automatic Error Handling - What do you do?

[Jeffrey Habets]

QUOTE (crelf @ Sep 8 2008, 04:00 AM)

Oh - and this is accessible through the Help menu too...

Yep, I now all of these 'tricks'.. But I still would like to see possible generated error codes with the function descriptions in the manual. In some cases I want to present a custom error message to the user (with explanations on what to do to resolve, etc.) instead of just presenting the sometimes (to the user) cryptic default explanations. Now I often just trial and error the different use-cases I want to catch and note the error that needs to be filtered.

QUOTE (crelf @ Sep 8 2008, 04:00 AM)

That looks like you really tore it out of a LabVIEW manual

Yeah, I regret it already..

[Mark Smith]

QUOTE (Jeffrey Habets @ Sep 8 2008, 02:03 AM)

Yep, I now all of these 'tricks'.. But I still would like to see possible generated error codes with the function descriptions in the manual. In some cases I want to present a custom error message to the user (with explanations on what to do to resolve, etc.) instead of just presenting the sometimes (to the user) cryptic default explanations. Now I often just trial and error the different use-cases I want to catch and note the error that needs to be filtered.

Yeah, I regret it already..

http://lavag.org/old_files/monthly_09_2008/post-906-1220860884.png' target="_blank">

I second what Jeffery said - it's not a question of being able to explain the error after it happens, it's a question of knowing exactly what errors might be generated so I can make intelligent choices of how to handle them at run time in my deployed applications. Seems there should be a better way than just trying as many potential run-time scenarios as one can think of and then writing the code to handle the errors generated - what about those scenarios you didn't anticipate? Now I've potentially got a customer calling and asking why his system just generated some error that shut down his test when if I had explicit knowledge that error could be generated I might have been able to handle it much more elegantly.

Mark

[TobyD]

QUOTE (ASTDan @ Aug 28 2008, 11:12 AM)

So how about it. Error Handling Techniques at NI week 2009 by crelf!

QUOTE (crelf @ Aug 28 2008, 11:32 AM)

Sure - remind me when NI's calling for presentation submissions and I'll put my hand up for it.

Consider yourself reminded (I don't actually know when NI calls for presentations, I might already be too late). Of course, I'm hoping the presentation notes will be made available as I won't be able to attend (all non-critical travel has been cut from the budget).

I'm still struggling with my error handling. I was able to glean some ideas from the JKI State Machine, but I still feel like I have a lot to learn in this department.

[ASTDan]

I saw in the NI week 2009 program a presentation by VI engineering on Error Handling.

:thumbup:

[TobyD]

QUOTE (ASTDan @ May 20 2009, 02:34 PM)

I saw in the NI week 2009 program a presentation by VI engineering on Error Handling.

:thumbup:

Excellent! I guess I should have checked first.

[crelf]

QUOTE (TobyD @ May 20 2009, 04:55 PM)

Consider yourself reminded.

QUOTE (ASTDan @ May 20 2009, 05:34 PM)

I saw in the NI week 2009 program a presentation by VI engineering on Error Handling.

Yep, Brian Gapske (V I Engineering, Inc Test Software and Integration Group) and I will be co-presenting "Advanced Error Handling in LabVIEW". I've started a thread here to ask for input on what you'd like to see in our presentation, so if you've got any ideas then absolutely let us know.

[TG]

QUOTE (TobyD @ Aug 27 2008, 11:16 PM)

I'm curious what people think of the Automatic error handling options in LabVIEW. Is this something you leave enabled? Do you disable it? Why?

http://lavag.org/old_files/monthly_08_2008/post-8758-1219878956.png' target="_blank">

I enable it only when debugging, otherwise I leave it off.

I prefer to handle errors in my code, however sometimes code runs funny or has errors that are not trapped because of lack of dataflow for error channel etc

In those cases I turn it on and let labVIEW give me a clue about where I may have screwed up..

[Shaun Hayward]

I tend to leave it on for that very reason - under normal circumstances every single error should be trapped and either dealt with internally by the VI (if its expected - ie EOF error etc), or sent out on an Error Out terminal. However, it's all to easy to forget to wire an error terminal (esp. when deadlines loom and your trying to code at warp speed - and yes, I know no one here does that... ever ) and the automatic error pop-up can really speed up tracking those things down.

Shaun

[Aristos Queue]

QUOTE (mesmith @ Sep 8 2008, 09:52 AM)

I second what Jeffery said - it's not a question of being able to explain the error after it happens, it's a question of knowing exactly what errors might be generated so I can make intelligent choices of how to handle them at run time in my deployed applications. Seems there should be a better way than just trying as many potential run-time scenarios as one can think of and then writing the code to handle the errors generated - what about those scenarios you didn't anticipate? Now I've potentially got a customer calling and asking why his system just generated some error that shut down his test when if I had explicit knowledge that error could be generated I might have been able to handle it much more elegantly.

Look at the online help for Obtain Queue. Search the help for the phrase "This function might return". Is this the sort of thing you're wanting to see on all functions?

[Neville D]

QUOTE (Aristos Queue @ May 22 2009, 01:42 PM)

Look at the online help for Obtain Queue. Search the help for the phrase "This function might return". Is this the sort of thing you're wanting to see on all functions?

Exactly. That would help find other possible errors to deal with, when an error from a particular function pops up during debug.

Hmm.. never noticed that before. Is it a new addition? (Good work though!!)

Neville.

PS And while your at it, it would be nice to remove the explanation of the error in and error out clusters which are mostly unnecessary. A simple link to explain what they are would REALLY clean up the help functions, and help focus attention to other parameters which are always more important.

[Jeffrey Habets]

QUOTE (Aristos Queue @ May 22 2009, 10:42 PM)

Look at the online help for Obtain Queue. Search the help for the phrase "This function might return". Is this the sort of thing you're wanting to see on all functions?

Yes, exactly... But it deserves a more prominent space, a bold header: Possible Error codes and the errors should be in some sort of table form with the explanations right there, in-place. (Or at the very least a direct link to the correct place in the error-table..) Now I still have to go and look the error-code up to know what it means.

[TG]

I've recently started using the automatic error handling. It's annoying, but worthwhile for catching those unwired errors.

Maybe someone knows, is there a way to attach a custom handler or callback to the automatic error handler? (I would occasionally like to inspect, or even modify, my program state when the automatic error handler pops up.)

Thanks,

Joe Z.

I realize now this is a relatively old thread

I don't think so Joe but you can get the behavior you wish with a state machine that is setup to handle both normal states and an error state. Errorr handling is best done by designing architectures to handle them from the ground up. I believe dataflow concept makes this necessary. Its one thing to report an error, quite another to handle it and return to the beginning of the dataflow..

You could write a generalized error handler VI.

Then when an error occurs you could call this VI and have it handle the error based on its number or message. Since its a VI call you have a way to determine if the handler actually 'handled' the error because itcan return information back to you.

The only catch is you need to call this VI when the error occurs, hence the need for designing a state machine that can detect error (after the state) and then redirect to the error state for handling.

You then need to know that the error was handled correctly.

If it was handled nicely you can go back and retry the prior state in the machine, else you escalate the error or close out.

Its a technique talked about in 'LabVIEW Advanced Programming Techniques.' I use it a lot and it is helpful especially with controlling peripherals which don't always behave

BTW I turn on error handling to help troubleshoot and its great for catching unwired situations.