LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is shutdown/close app on Error the typical error response you program? Is it typically the best?

I always get to a point in my code where I find myself hemming and hawing about what to do when an error happens. I would ideally like to be clever enough to have code that is so genius that it can figure out how to deal with it and not close. I typically try to make errors impossible, like disabling certain controls until conditions have been met for them to actually function (eg, a "Process" button being greyed out until there's a valid path to a valid file in a path control). If that's not possible I'll do some defensive programming to coerce or reject an input. But it can be difficult to come up with every possible way a program can be screwed up, especially when it involves talking to external hardware devices. Whenever I think "this time I'm going to try to make it so that errors are programmatically handled" I quickly realize the added complexity is significant or impossible and also adds many new ways for errors to occur.

 

Eventually, I throw up my hands and decide that just shutting down is the easiest/best response to errors. I've seen some decent examples/others' programs that seem to be able to not need to shutdown on error, but they're always just very dead simple state machines, with few states and not much functionality compared to the typical sort of thing I happen to be working on at the time (lots of asynchronous modules, controlling hardware, lots of ui functions, tcp, etc).

 

So is just shutting down the best thing to do (with an effort to put things in a safe state where possible and capturing the error to file for examination)?

 

I suppose this makes all errors of the "unhandled exception" type.

0 Kudos
Message 1 of 4
(821 Views)

Once you have prepared for user errors, like disabling buttons until they are needed and handling things like canceling an open file dialog elegantly.

 

All you can do is display an error message (maybe a more informative custom error message) and gracefully abort if there is no way to recover.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 2 of 4
(798 Views)

Creating a User Interface that is idiot-proof is especially challenging for developers.   Developer tend to have a grasp of what steps are needed and what order they should occur in.  If not, they likely have to debug the code.

 

Then you stick MyWonderfulApplication.exe in front of a user and learn you significantly underestimated the user's idiocy.

 

Better: Get the User's Story first!  Sit down with them, talk them through the task of operating the code.  You would be astonished how often the user knows how the code should work but hasn't thought about how they want to work with the code.  So walk with them but suggest things like, "Would you like a separate panel to pop-up and configure that?  I can set it up so you can change that, save or load to/from file between executions of the main function. " and "Suppose someone replaced Dev XYZ1 With  XYZ2 because XYZ1 is out to the calibration lab,, what would you want the software to do? What if it's simply missing?"  Not only do you get some idea of what they need to see and when, you also train them to expect a certain workflow so their idiocy factor improves.

 

There are two special error messages you never want to display.

1) Error: User is a moron!

2) Error: Call me at extension 5*** for help


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 4
(785 Views)

Actually there is a variant of Murphy's law. You can make a software idiot proof but you can't make it engineer proof. Engineers will always find novel ways to break your software! 😀

 

More seriously though, error messages are useful but you need to be careful to not display error messages all the time or simply sink errors to /dev/null all the time. There are errors you can't do anything about such as the user canceling a file dialog. LabVIEW reports this as an error, but usually it isn't and you should simply act like the user hasn't even started to select a file. 

Then there are communication errors with devices. Here you have expected errors like timeout errors that simply tell you that the device didn't respond (yet). This could be a very legitimate situation, for instance in network communication. The remote side simply hasn't to tell anything right now, so ignore the timeout and go back and try again. Most other errors usually mean that the connection got disrupted, for instance because someone unplugged the network connector, a router had a temporary black out or some other such thing. Here you have to close the current connection and try to reconnect back. And that (re)connection may not always succeed, so it may be useful to retry a few times before giving up and sometimes to simply try (re)connecting for as long as your application is running. All this always depends on the actual use case. Instrument communication busses are a tiny but less complicated but the principle is similar.

 

Simply quitting on error is something I would only do for quick and dirty test applications. A real application should not just bail out on any error except things like memory corruption or out of memory situation and such. Here there is not really much you can try to do anymore as the consistency of your entire process is usually compromised and pretty much anything you can think up of trying will simply mess up things even more. So the safest thing is to quit and start up with a fresh slate.

Rolf Kalbermatter
My Blog
Message 4 of 4
(756 Views)