How to show all possible errors generated by a given VI

[Kevin_Price]

---

@rolfk wrote:

...the only useful recourse is to log the error and inform the user and/or restart the operation completely.

---

This little bit of enlightenment is like Zen and the Art of Error Cluster Maintenance.

My very early coding paid little heed to errors.

My middle stage, when I was trying *really hard* to handle errors thoroughly, I wasted an inordinate amount of time trying to have a specific reaction to every individual error I could anticipate.

Then finally I reached the moment where I realized what rolfk and others have been saying in this thread.  It's been *hugely* beneficial to realize that the only reasonable way to code for the vast majority of errors is to log them all and alert the user about some. There are relatively few exception cases where the code needs to to try some auto-recovery.

-Kevin P

[Mark_Yedinak]

---

@Kevin_Price wrote:

---

@rolfk wrote:

...the only useful recourse is to log the error and inform the user and/or restart the operation completely.

---

This little bit of enlightenment is like Zen and the Art of Error Cluster Maintenance.

My very early coding paid little heed to errors.

My middle stage, when I was trying *really hard* to handle errors thoroughly, I wasted an inordinate amount of time trying to have a specific reaction to every individual error I could anticipate.

Then finally I reached the moment where I realized what rolfk and others have been saying in this thread.  It's been *hugely* beneficial to realize that the only reasonable way to code for the vast majority of errors is to log them all and alert the user about some. There are relatively few exception cases where the code needs to to try some auto-recovery.

-Kevin P

---

I agree with what you and Rolfk are saying. I would only add that when doing general error handling, besides logging the system may choose NOT to move forward with certain operations because the system may be in an unknown state.

[Kevin_Price]

---

@Mark_Yedinak wrote:

---

I would only add that when doing general error handling, besides logging the system may choose NOT to move forward with certain operations because the system may be in an unknown state.

---

That's a really important point, and worth repeating.

-Kevin P

[BertMcMahan]

It's hilarious to me that the example of what "good error documentation" looks like has one error type that's just "an I/O error occurred". How generic can you be? In LV you'd get some super specific error code.

I'm not a full time dev, but have been coding a reasonable portion of my job for nearly a decade, and the only time I've needed to handle certain error codes one way and other errors another way is when trying to intentionally cause a DAQ underflow error when I'm trying to ensure the buffer is written in its entirety before stopping the process. I'll admit that I've had different error codes generated by different devices for the same underflow error, though that doesn't seem like an issue with errors in general, more of an issue with DAQmx having some unfortunate overlap. In this case I need to know if the error was the one I was looking for (buffer empty, continue with program) or something else (DAQ error, sounds like someone unplugged it, halt program).

I don't have any other examples off the top of my head, other than the Actor Framework using specific error codes to denote specific Stop conditions... which is extremely well documented 😉

I'll echo what everyone else said- robust code just needs to know "A function failed" to be able to move along. The code nearly never needs to know WHY a specific function failed.

[sbus]

So we have a robotics application - a controller that moves physical objects that can cause injury to personnel or damage to property.

We also have business issues such as meeting our delivery deadlines and meeting customer demand.

What that means is: [1] when there's an error, we need to know what it was, so we know if it is recoverable (we retain robot state) or unrecoverable (we risk issues with position unless we reset the robot first), and [2] resetting the robot takes a lot of time and we cannot afford to do it unless it's absolutely necessary.

So simply knowing that 'something failed' and knowing WHY it failed are to grossly different things. The former is great - if we are talking about whether to kill your Gameboy in the middle of a game. The latter is important if we don't want a huge pesticide release because the robot made a 'mistake'.

[mcduff]

Some tool kits have custom error codes that make finding all errors difficult.

You can try the Error Code Database with a variety of numbers, no idea of the ranges, to get some errors. (The VI is buried in the Simple Error Handler.)

mcduff

[Mark_Yedinak]

Shouldn't your state machine know what is recoverable and what isn't? You say you are keeping track of state and that should be sufficient. For example, communication errors can be handled within a well defined library which can handle retries/reconnects automatically and then report if communications have failed or not. Perhaps if you would give some specific examples of what types of things you are trying to accomplish then perhaps we could give more specific advice. I have a system running 24/7/365 controlling megawatts of power and to be honest, it doesn't really care about specific error codes. The system state machine knows what state it is in and if an error occurs, it takes appropriate actions. It really doesn't need to know the exact error code to say things need to be done.

It would be impossible, even if you could get the documentation, to handle every possible error code that could occur. As mentioned, even if you could, the code would be very fragile and very difficult to maintain.

In your example, let's say we have an out of position error. I don't know what you are using for your feedback but lets say you have something. Depending on your system state you could handle things differently. If we are in some critical location and an error occurs, stop immediately and notify. If we are in a safe zone and position if off, try to readjust. See where I am going with this? My system design and state machine dictate what and when things should be done rather than I received error code 1234 here.

[billko]

I think if you drop an "error ring" onto your block diagram, you get quite a detailed list of all the errors that LabVIEW can throw.