Scary error dialogs

Posted on Sunday 1 April 2007

When developing professional software, one thing that you want to avoid is scary error dialogs — you don’t want people to be afraid to use your software and you certainly don’t want to make them feel like they did something wrong. Why did your software let them do something wrong, in the first place?

While working on OpenG Builder, I tried to run a built LabVIEW executable that had some linking problems and this is the error message that I was presented by the LabVIEW Run-Time Engine:

Error Message

Click on the image above
and hold onto your seat!

I would recommend that NI rethink the algorithm that constructs this dialog. Certainly, my EXE has some problems, but does this message do anything to help me fix them?

At JKI we have a few policies on error handling in commercial/professional applications:

1) Avoid errors — if you know about a condition that will cause an error, test for it and then intelligently avoid it.

2) Handle errors — if a known error does happen occasionally, try to handle it programmatically.

3) Friendly dialog — give the user a message that actually helps them solve the problem.

4) Native Error handling dialogs are bugs — the end user should never see a native error dialog (e.g., LabVIEW’s General Error Handler and Simple Error Handler). We still leave these dialogs in-place, but only after we’ve attempted items 1-3.

5) Log the error details — log the error details so that programmers can trace the cause.

Of course, when you’re writing one-off applications (quick and dirty prototypes), you don’t need to go to such great lengths, but it’s still good to be aware of these ideals.


2 Comments for 'Scary error dialogs'

  1.  
    Aristos Queue
    April 2, 2007 | 8:07 am
     

    This is actually the General Error Handler.vi composited.

    Prior to (some recent version of LV whose exact number I don’t remember) you would get a GEH dialog for EACH ONE OF THESE with just an OK button. That behavior went back to the dawn of time. You couldn’t break out, you couldn’t stop it, they just kept coming. Terminator 2 in dialog form. One day, I couldn’t take it any more and I taught the AppBuilder to aggregate all the messages into a single output.

    Is the output helpful? Well, that’s a problem for each individual error code. There’s not much this dialog could do to be more helpful since the output could be litterally any error that can be generated by LV or any module or even user VIs. It does seem that whoever added those error codes should’ve been more explicit about what was going wrong.

    There should be carriage returns between the messages. Don’t know why those aren’t there.

    If you’ve got a proposal for how to better display what is effectively a log file dump, file ‘em with NI. This is basically a crash log — one the user frequently can do something about and thus useful to display.

  2.  
    April 2, 2007 | 8:19 am
     

    Aristos Queue: Thanks for the explanation and history. It’s certainly nice to know that we’re heading in the right direction. Here are a couple quick suggestions… First, I would filter out duplicate items — you’ll notice that there is a tremendous amount of duplication. Second, I would probably truncate the message, at some point, and then allow the user to open the log file to see more — you’ll notice that there are actually error messages that run off the bottom of the dialog and there is no way to see them. – Thanks

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 775 access attempts in the last 7 days.