Jump to content

Stay away from the native Error Handlers


eberaud

Recommended Posts

lol :D 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 by smithd
Link to comment

lol :D 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.

Link to comment

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!" :P

Link to comment

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.

Link to comment

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!" :P

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 by smithd
Link to comment

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 by ShaunR
  • Like 1
Link to comment

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.

Link to comment

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:

 

post-4441-0-06221900-1454514644.png

 

 

  • Like 2
Link to comment

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?

  • Like 1
Link to comment

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 :wub:

 

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

 

For posterity! (circa 2009) :lol:

 

post-15232-0-03326100-1454956316.png

Edited by ShaunR
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.