Stay away from the native Error Handlers

[eberaud]

This thread is not a question, I just wanted to share the experienced I gained today by troubleshooting our application:

 

Symptom:

 

Engine A encounters an error (expected, so no problem so far) and display it to the user.

Engine B, which is totally unrelated to engine A, freezes, and only comes back to like after the user acknowledges the error message from engine A.

 

Consequence:

 

The software engineer (aka me) is pulling his hair and yelling "what the h*** is going on in here?" Then he does some diligent troubleshooting and finds the culprit.

 

 

Explanation:

 

Engine A calls the "Simple Error Handler" VI, which itself calls the "General Error Handler" VI. This VI analyzes the error and opens a pop-up when there is an error to display.

 

Engine B calls a subvi which calls a subvi...........which calls a subvi which calls "General Error Handler". This subvi doesn't have any error, but still calls "General Error Handler" because it knows that if there is no error, "General Error Handler" will simply return without doing anything. Problem: "General Error Handler" is not reentrant, meaning while it's busy waiting for the pop-up it called to be closed, it can't be used by the sub-sub...subvi of engine B. Therefore engine B is in a frozen state.

 

Conclusion:

 

Those error handlers are a great quick tool for creating super basic application, but not appropriate at all for large, professional applications. I'm pretty sure some of you will think "Well duh, we've been knowing that since LabVIEW 1.0!". 

[smithd]

lol  No really, I didn't know that. Thats kind of funny.

 

In general I try to use the simple error handler only on exit, and even then its just a bad habit -- nobody ever ever ever ever reads the dialog. You're better off saving it to a log in a folder called "delete me" on the user's desktop . I try to handle errors gracefully and then report the failure in a status log on the bottom of the window (or in the temp dir). That might not be perfect, but at least it keeps a log so people can go back and see "oh man I got that error thats why that operation failed" before completely ignoring the rest of the error message and code and moving on with their lives.

 

The other thing I find for myself is that I loathe people who say "simple error handler is bad, lets use 1 button dialog". Its great the first time as it gives you immediate blocking feedback on what you did wrong. And then every subsequent time you see it you want to kill the developer. Thats another reason I find the status bar to be the least worst option. The user tries to do something silly like making a new test with no name, you put a message in the status bar, they say "woops" and then they don't blame the code (ok they don't blame it as much). 

 

Has anyone else found a better way of gracefully showing errors in a non-obnoxious way?

Edited February 2, 2016 by smithd

[Rolf Kalbermatter]

lol  No really, I didn't know that. Thats kind of funny.

 

In general I try to use the simple error handler only on exit, and even then its just a bad habit -- nobody ever ever ever ever reads the dialog. You're better off saving it to a log in a folder called "delete me" on the user's desktop . I try to handle errors gracefully and then report the failure in a status log on the bottom of the window (or in the temp dir). That might not be perfect, but at least it keeps a log so people can go back and see "oh man I got that error thats why that operation failed" before completely ignoring the rest of the error message and code and moving on with their lives.

 

The other thing I find for myself is that I loathe people who say "simple error handler is bad, lets use 1 button dialog". Its great the first time as it gives you immediate blocking feedback on what you did wrong. And then every subsequent time you see it you want to kill the developer. Thats another reason I find the status bar to be the least worst option. The user tries to do something silly like making a new test with no name, you put a message in the status bar, they say "woops" and then they don't blame the code (ok they don't blame it as much). 

 

Has anyone else found a better way of gracefully showing errors in a non-obnoxious way?

 

I have my own error handler loop in every app. This loop polls a queue for new error messages, displays them in an automatic scrolling string control (that in some applications is optional), logs the error to a log file (and at the same tome looks for really old log files that can be deleted) and also optionally shows a floating but non modal dialog.

 

I have an Error Handler VI which looks just like the standard Error Handler and which does all the things about optional filtering of the errors, looking up appropriate error messages, before sending the error to the queue and also by default clearing the error from the error out cluster.

 

Works pretty neat, quite scalable and has provided me many times with helpful log files about what errors the customer encountered.

[ShaunR]

Has anyone else found a better way of gracefully showing errors in a non-obnoxious way?

 

Without getting into error strategies; I haven't used the default LabVIEW handler in real applications since, probably, version 7. Yes I do use it for examples and quick checks of the error wire for debugging but I want a dialogue that is uniform with the rest of the look of the application for real apps. So I have a customisable 3 button dialogue that has images, on-the-fly translation, can query the database and has a timeout. It is used for errors, about boxes and confirmations - pretty much all dialogues - so the interface is consistent.

 

I'm not a fan of the status bar for errors just as I'm not a fan of the status bar for mouse-over help. A one liner is not enough for users. They really need a plain [insert your language here] error message and an explanation of how to proceed. From a personal perspective, It just confuses me between something that's nice to know (which I associate with status bars so don't look often) and something I must know.

 

For settings, I am a fan of the browser style of flagging errors. I.e change the background colour of the item and a message saying "sort that out!"

[mgunning]

Note also that some of the other LabVIEW VIs have the general error handler inside them, "Write to Spreadsheet File.vi" and "Read from Spreadsheet File.vi" for example.

[eberaud]

The other thing I find for myself is that I loathe people who say "simple error handler is bad, lets use 1 button dialog". 

 

Definitely. The worst thing about the LabVIEW 1 or 2-button dialogs is they use the root loop, so while displayed, many functions such as Open VI Reference just have to wait their turn to access the root loop, causing very undesirable behaviors! A few months ago I tracked down and replaced all those dialogs with my own standard dialogbox.

[hooovahh]

For those more curious here is an article talking about the root loop and how the one button dialog can block an open VI reference call.

 

http://www.labviewcraftsmen.com/blog/the-root-loop

[smithd]

I have my own error handler loop in every app. This loop polls a queue for new error messages, displays them in an automatic scrolling string control (that in some applications is optional), logs the error to a log file (and at the same tome looks for really old log files that can be deleted) and also optionally shows a floating but non modal dialog.

 

Ah yeah, thats what I meant, a scrolling string rather than a status bar.

 

I'm not a fan of the status bar for errors just as I'm not a fan of the status bar for mouse-over help. A one liner is not enough for users. They really need a plain [insert your language here] error message and an explanation of how to proceed. From a personal perspective, It just confuses me between something that's nice to know (which I associate with status bars so don't look often) and something I must know.

 

For settings, I am a fan of the browser style of flagging errors. I.e change the background colour of the item and a message saying "sort that out!"

Thats interesting, I think because I do more RT stuff I tend towards thinking of RT as 'the important thing' and it does all this detailed error logging and recovery while the UI is more...I guess friendly? So if the user does something wrong its not really an error its just a mistake, so the scrolling log trains people how to not do that. Your background color thing is I think along the same lines and I like that idea. I've done something like that once or twice when I felt fancy (pop in a hidden red X next to an error control in my case, but same concept). It does feel like that would get tedious after a while. Do you have good system for setting that up or do you just bite the bullet and do it manually, one by one?

 

 

Have any of you ever actually gone all the way and said goodbye to the standard labview error cluster? Or is it just too ubiquitous to get around?

Edited February 3, 2016 by smithd

[ShaunR]

Thats interesting, I think because I do more RT stuff I tend towards thinking of RT as 'the important

thing' and it does all this detailed error logging and recovery while the UI is more...I guess friendly?

So if the user does something wrong its not really an error its just a mistake,

so the scrolling log trains people how to not do that.

 

If the user makes a mistake it is an error (on the users part). If it he needs to interpret a 20 GB log file to guess why, then that's an uncaught error with no recovery (on the programmers part). I always say, errors are for programmers only because users just want software that works-preferably with one button "Start". As a user of your software I do''t want to be "trained" how to interpret your logs of gibberish or wade through reams of irrelevance to find out what to wiggle. I want to know whats wrong and what to wiggle so it works.

 

Your background color thing is I think along the

same lines and I like that idea. I've done something like that once or twice when I felt fancy (pop in

a hidden red X next to an error control in my case, but same concept). It does feel like that would get

tedious after a while. Do you have good system for setting that up or do you just bite the bullet and

do it manually, one by one?

 

Well. Changing a background colour doesn't require pre-defined controls on the front panel and is supported by all controls/indicators. I'm not sure how you used an image but I would imagine it needed an image control next to each unless it was a list/tree or something.

 

You can get (and save) lists of the controls and limits (from your database ) and have a generic check/set that just iterates over the visible controls and sets the colour and limits. This enables you to also tell the user why the value they entered is incorrect if it's outside limits and what is acceptable to enter. See the "Panel Settings Example" to see how this might work.

 

Have any of you ever actually gone all the way and said goodbye to the standard labview error cluster? Or is it just too ubiquitous to get around?

The cluster? For me, no. That's used also for sequencing.

Edited February 3, 2016 by ShaunR

[hooovahh]

I've seen others try to add more features to an error handing system, and embed the NI error cluster into a class, or another cluster, which can have more information like history, and more debug information.  There is a lot of information on the topic.  

 

https://lavag.org/topic/10741-updating-the-labview-error-handling-core/

 

You can go too far one way, or the other.  I mean even NI's error handling cluster could be reduced to just a boolean, Error or No Error.  I think doing that goes too far and the cluster and all that goes with it, is justified by the added functionality.  But I'm guessing that when the error cluster was made standard (LabVIEW 5?  3?) some thought it was more complicated than necessary, and a single boolean, or single integer would be enough.  Or you could add tons of functionality and add lot of overhead, to the point that it wouldn't be worth the effort.

 

In larger applications I generally wrap more functionality into the NI implementation by using a central error handler that keeps track of the errors, severity (which is hardly ever used), time of the error, module that it originated from, and the last 4 states the state machine went to leading up to the error.  This is also logged to a temp location.  So while I do use the simple error handler in smaller programs, the ones involving actors running in parallel get their own error actor.

[Darren]

Note also that some of the other LabVIEW VIs have the general error handler inside them, "Write to Spreadsheet File.vi" and "Read from Spreadsheet File.vi" for example.

 

We deprecated those VIs in LabVIEW 2015 and created new ones that use error in/error out instead of embedded error handlers:

 

 

 

[eberaud]

We deprecated those VIs in LabVIEW 2015 and created new ones that use error in/error out instead of embedded error handlers:

 

 That was a very good idea. I never liked those guys.

[ShaunR]

We deprecated those VIs in LabVIEW 2015 and created new ones that use error in/error out instead of embedded error handlers:

 

Untitled.png

 

Do they throw an error 4 when they read the entire file? (one of my pet peeves)

[Darren]

Do they throw an error 4 when they read the entire file? (one of my pet peeves)

 

Other than the error input/output, the functionality of the VIs didn't change. I'm not seeing an error when reading an entire file. I am seeing a *warning* 4 when specifying a number of rows to read greater than the size of the file, is that what you're referring to?

[ShaunR]

Other than the error input/output, the functionality of the VIs didn't change. I'm not seeing an error when reading an entire file. I am seeing a *warning* 4 when specifying a number of rows to read greater than the size of the file, is that what you're referring to?

Aha. You've deprecated it to a warning. You are a legend

 

Now please walk over, and smack with a wet sock, whoever is responsible for "Read From Text File" 

 

For posterity! (circa 2009)

 

Edited February 8, 2016 by ShaunR

[Darren]

Aha. You've deprecated it to a warning. You are a legend

 

I honestly don't remember making that change. Maybe I did, maybe I didn't. Only Perforce knows for sure.

[ShaunR]

I honestly don't remember making that change. Maybe I did, maybe I didn't. Only Perforce knows for sure.

 

Well. To be fair. The originals didn't have error clusters; just a boolean for when EOF was reached. But you could have (and am glad you didn't) normalised the behaviour with the Read from Text File function which is an enormous pain.