Automatic Error Handling - What do you do?

[TobyD]

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?

[Val Brown]

QUOTE (TobyD @ Aug 27 2008, 04: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 disable it and wire through Error in and Error out clusters manually.

[jdunham]

I mostly hate it, but I leave it on. It's annoying when doing initial testing. However, very occasionally it finds an error cluster which I forgot to wire, sometimes in the middle of a crowded diagram, and that makes it worth it.

[Mellroth]

QUOTE (Val Brown @ Aug 28 2008, 04:15 AM)

I disable it and wire through Error in and Error out clusters manually.

I second that. The main reason for this is that I like to manage error dialogs my self.

/J

[LAVA 1.0 Content]

QUOTE (jdunham @ Aug 28 2008, 01:06 AM)

I mostly hate it, but I leave it on. It's annoying when doing initial testing. However, very occasionally it finds an error cluster which I forgot to wire, sometimes in the middle of a crowded diagram, and that makes it worth it.

Ditto that.

Ben

[Aristos Queue]

I use it heavily during initial design. When code is finished, I turn it off, error cases either wired or consciously ignored.

[James N]

QUOTE (JFM @ Aug 28 2008, 01:30 AM)

I second that. The main reason for this is that I like to manage error dialogs my self.

/J

I will third that.

For example, we have a standard VI that creates a directory. The auto error handler will post an error if the directory already exists... well... OK. That's what I wanted.. a directory there. If it's already there, then good!

As I type this I realize that if I know an error routinely happens, I should avoid it. I should probably check if the directory exists first. So maybe the auto error will point out places that I should correct.. like jdunham does.

Thanks a lot.. now I feel compeled to turn on the automatic error handling...

-James

[edit]

I just check the VI that initializes paths. I do check if the directory already exists. Sometimes I'm good and don't even know it.

[crelf]

QUOTE (Aristos Queue @ Aug 28 2008, 09:22 AM)

I use it heavily during initial design. When code is finished, I turn it off, error cases either wired or consciously ignored.

Ditto.

[ASTDan]

I personally turn it off all the time. I try to build in my error handeling in the begining and I like to see how my code will perform with my own Error Handeling.

This brings up something I am really interstied to learn. How do other people do their error handeling? This I think would make a great NI week topic. I have been thinking about developing a presentation on the topic but I feel I don't have scope on different methods of error handeling and comparing them to my own hair brained methods.

Dan

[crelf]

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

I personally turn it off all the time. I try to build in my error handeling in the begining and I like to see how my code will perform with my own Error Handeling.

That's fine as long as you are absolutely sure that you get complete error cluster coverage. For example, do you wire up the errors on the "Format into String" primative? I sometimes miss those and am delighted when LabVIEW pops up an error if I've buggered something up.

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

This brings up something I am really interstied to learn. How do other people do their error handeling?

We have a bunch of reuse VIs that do anything from present errors to the user, file-defined filtering, writing errors to a FIFO file, ... What do you mean by "do"?

[TobyD]

QUOTE (Aristos Queue @ Aug 28 2008, 06:22 AM)

I use it heavily during initial design. When code is finished, I turn it off, error cases either wired or consciously ignored.

Thanks for all the replies. I tend to follow this paradigm myself, but this brings up the follow-up question...Is it OK (from a best practices viewpoint) to consciously ignore errors? I do it when I need to execute a section of code regardless of what is on the error wire, but I want the error to propagate through. I always feel a little a little guilty about leaving those error I/Os unwired though

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

This brings up something I am really interstied to learn. How do other people do their error handeling? This I think would make a great NI week topic.

I would definitely be interested in a presentation on error handling. It seems there are many ways to get it done, but not really any prominent best practices on the subject.

[Tim_S]

QUOTE (TobyD @ Aug 27 2008, 07: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?

Automatic error handling has been one of the options I turn off once LabVIEW is installed. The why is it would report errors and wait for a user prompt when the systems I work with do not have a user standing in front of them (it's mostly production equipment).

QUOTE

This brings up something I am really interstied to learn. How do other people do their error handeling?

We have a centralized alarms screen that logs to a database.

[Yair]

I'm with the leave-it-on-but-handle-errors-camp. This is good for catching places where you missed wiring an error cluster, although if you want, the VI analyzer also has a test for this.

In any case, when you compile an executable, errors won't pop up under any conditions, so leaving it on only applies in the IDE (where it can also be globally disabled).

That said, there are cases where leaving it enabled can give you trouble. I was once asked to debug a VI which had a primitive (open app ref, I think), which returned both a reference (although an unusable one) and an error. The error out wasn't wired and I didn't think to check it because the VI was returning a reference and I had AEH on. What I didn't realize was that the person who wrote the VI didn't have AEH enabled and so the VI didn't have it enabled. Without relying on it, I might have wired the error out terminal sooner and found the source of the problem.

If you want, you can read this discussion for more.

P.S. Regarding your question, yes, there are cases where it's OK not to handle errors (e.g. certain property nodes, disconnected segments), but you have to be very careful about this.

[ASTDan]

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

For example, do you wire up the errors on the "Format into String" primative? I sometimes miss those and am delighted when LabVIEW pops up an error if I've buggered something up.

I have not become comforatble with the "Format into String" primative. I recogineze it is suppior to concatinating stings and manually changeing data types. I have just not spent the time to become comforable with it. It is on my list

QUOTE

We have a bunch of reuse VIs that do anything from present errors to the user, file-defined filtering, writing errors to a FIFO file, ... What do you mean by "do"?

I guess Error Handling architectures pros and cons. For example I have an "Error" case in my state machine. I have built a Reuse Error VI that can handle standard and User created Errors. This admiditly is probably simplistic but I found it works for what I do.

I have seen people put their Error handling in another loop. I think Peter Blume Promotes this. I think this is a good idea but for smaller projects....I don't know if the overhead is worth the functionality. I also think loggering errors to a text file is a good idea. (Need to create reuse vi for that. Again on my list)

What I think would be a good idea is for a discussion on this to flush out best practices. I think there are a lot of different ways to handle errors and depending on what your doing and using the best method for your application.

My $0.01

Dan

[crelf]

QUOTE (TobyD @ Aug 28 2008, 12:05 PM)

Is it OK (from a best practices viewpoint) to consciously ignore errors? I do it when I need to execute a section of code regardless of what is on the error wire, but I want the error to propagate through. I always feel a little a little guilty about leaving those error I/Os unwired though

Good point. The answer is "it depends". We have a reuse component that filters errors, so you can implicitly force it to ignore specific errors rather than not wiring up error clusters.

[jdunham]

QUOTE (crelf @ Aug 28 2008, 10:28 AM)

Good point. The answer is "it depends". We have a reuse component that filters errors, so you can implicitly force it to ignore specific errors rather than not wiring up error clusters.

[crelf]

QUOTE (ASTDan @ Aug 28 2008, 01:14 PM)

I have not become comforatble with the "Format into String" primative.

I don't mean that primative specifically - I mean any of the primatives that do formatting (and coincidentally don't have their error clusters in the LL and LR corners). I think most people forget about those because either they assume that what their inputs are always going to be appropriate, or they forget about the error clusters due to the primative's connector pane layout.

QUOTE (ASTDan @ Aug 28 2008, 01:14 PM)

I guess Error Handling architectures pros and cons. For example I have an "Error" case in my state machine. I have built a Reuse Error VI that can handle standard and User created Errors. This admiditly is probably simplistic but I found it works for what I do. I have seen people put their Error handling in another loop. I think Peter Blume Promotes this. I think this is a good idea but for smaller projects....I don't know if the overhead is worth the functionality. I also think loggering errors to a text file is a good idea. (Need to create reuse vi for that. Again on my list)

Each of those patterns have their merits, but none of them are catch-alls. I suppose what I'm trying to say is that I haven't found an error handling pattern that's completely scalable across the breadth of projects that I do, so I've created two or three reusable components that I can select during the design phase of a project. I'm not saying that a completely scalable holy grail is out there, just that I haven't found it

[jzoller]

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.

[ASTDan]

QUOTE (crelf @ Aug 28 2008, 02:02 PM)

Each of those patterns have their merits, but none of them are catch-alls. I suppose what I'm trying to say is that I haven't found an error handling pattern that's completely scalable across the breadth of projects that I do, so I've created two or three reusable components that I can select during the design phase of a project. I'm not saying that a completely scalable holy grail is out there, just that I haven't found it

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

[crelf]

QUOTE (jdunham @ Aug 28 2008, 01:44 PM)

As crelf pointed out, it's important to have the ability to filter out specific errors. I think the built-in function to clear error codes ("Clear Errors.vi")is really harmful, since you should only clear error codes which you are expecting.

Right - don't ignore everything. Even if you think you know all the errors that a node might generate, there may be one or two important ones that you don't know about. That's why you should also use the "ignore errors inside node" option for methods/properties. All of these things are powerful, but you've got to think about when are where to use them.

QUOTE (ASTDan @ Aug 28 2008, 02:12 PM)

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

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

QUOTE (jzoller @ Aug 28 2008, 02:05 PM)

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.)

I don't know of a way to do it without editing the VI in vi.lib... That said, I know several folks who replace the General Error Handler with thier own custom versions.

[Mark Smith]

OK, I'm a little late to this thread, but I was just coding in LabVIEW and trying to do some intelligent error handling and 1) either I identified a glaring deficiency in LabVIEW or 2) I'm just ignorant and don't know where to look, but is there any document or help file or something that specifies what error codes LabVIEW functions return? And I don't mean an error code list that has headings like "General" - 1094 - 1157 where I get to guess which one gets generated or just try to handle the 64 possible errors. I mean something like the MSDN on-line support where I can find which exceptions a method is expected to throw in the documentation for that specific method. I open the LabVIEW help for a given function and sometimes there's some info (like for Obtain Queue) but most often there's not. This makes it really hard to anticipate and handle run-time errors - what do you guys do?

[Jeffrey Habets]

The error are grouped in the LV help:

I do agree that it would be a big help if possible generated error's would be mentioned with the VI/function help instead of a seperate place. Particularly for HW I/O functions.

[Aristos Queue]

QUOTE (crelf @ Aug 28 2008, 01:32 PM)

I don't know of a way to do it without editing the VI in vi.lib... That said, I know several folks who replace the General Error Handler with thier own custom versions.

I also know one particular someone who may be replacing the GEH completely in some future LV version. I've got a couple years worth of requests built up. Note: This would definitely *not* be 8.6.1, should such a bugfix release be deemed necessary, nor would it be the immediate next full LV version. But it is on the roadmap.

[crelf]

QUOTE (Aristos Queue @ Sep 6 2008, 12:53 PM)

I also know one particular someone who may be replacing the GEH completely in some future LV version.

I'd love to be on the beta for that.

QUOTE (Aristos Queue @ Sep 6 2008, 12:53 PM)

...should such a bugfix release be deemed necessary...

QUOTE (Jeffrey Habets @ Sep 6 2008, 05:46 AM)

I do agree that it would be a big help if possible generated error's would be mentioned with the VI/function help instead of a seperate place.

Everyone probably knows this, but you can right-click on an error cluster and choose "explain error". This pops-up a dialog where it'll give you some more info. As an aside, you can then increment/decrement/change the error code in that dialog to see explinations of other error codes. This also works with http://wiki.lavag.org/Error_handling#Custom_Error_Codes' rel='nofollow' target="_blank">custom error codes too

[crelf]

QUOTE (crelf @ Sep 7 2008, 04:00 PM)

Everyone probably knows this, but you can right-click on an error cluster and choose "explain error".

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

QUOTE (Jeffrey Habets @ Sep 6 2008, 05:46 AM)

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