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