Developer Gripe: "An unknown error has occurred"

While at the Dynamics GP Technical Airlift two weeks ago, I was speaking with someone who mentioned that Management Reporter was driving them nuts with a generic error message:

An unknown error has occurred

That's it.  No further description, no error number, and no further clues as to the cause of the problem, when or how it occurred, or how it might be resolved.

In short, an utterly useless error message.

Coincidentally, Christina just wrote a blog post about one possible cause for this generic Management Reporter error.  Who knows how many other reasons may cause that error to occur.

This generic error message is coming from Management Reporter.  A relatively new, modern Microsoft product.  Not that Microsoft products are known for their illuminating error messages, but they don't get much worse that "An unknown error has occurred".

I'm no Super Hero Developer, but I have never written a program that had such a lame error message.  It's puzzling for a few reasons.

First, the fact that the message is displayed in a dialog box means that the error was detected or trapped by the application.  This means that some part of the application code anticipated that there could be some type of "error", is handling the error, and is displaying the error message.  I understand that not every possible error can be anticipated, but when an error is being thrown, and you have an error handler setup to display a dialog box, it is negligent to not provide any information to the user as part of the error message.  What would be the point?  Displaying highly technical or a very specific detailed message is better than nothing--at least the user can send more info to an administrator or consultant who can then evaluate it rather than spending hours aimlessly trying to guess the problem.  Or it can at least be sent on to Microsoft as part of a support case to help their internal debugging. 

Second, more generally, such a useless error message seems to indicate an application architecture or development methodology that is designed to not provide error information to the user.  That's not an accidental choice.  It's something that has to be intentionally, designed, coded, reviewed, tested, and released.  As I said, I'm not a Super Coder, but even I develop my relatively simple applications to capture and expose error messages.  It makes the customer's life easier, and it makes my life easier.  Why a development team for a commercial Microsoft software product would implement such a generic error message design is baffling to me.  If my applications can do it, certainly Microsoft could pull it off.

Last, I would argue that there is no such thing as an "unknown error".  There are only "expected errors" and "unexpected errors".  If you display an error dialog box, then by definition your application has detected the error, and the error is known.  Something caused that dialog to display based on some condition in your code.  You may not know the scenario or specific cause or details, but you fundamentally know that an error occurred.  However, that error may be expected or unexpected.  Expected errors are those that you anticipated and handle explicitly.  Unexpected errors are ones that you didn't anticipate, and handle generally (such as with an Unhandled Exception error).  An invalid GL account or an invalid date might be expected errors--you anticipated that a user may enter an incorrect value.  A divide by zero error might be unexpected--until you see it happen, identify the cause, and add validation to check for a zero denominator--and then it becomes an expected error:  "Hey, you can't divide by zero in that formula!".  In either case, you can capture the error and display a meaningful message with actual information that a human might find valuable.

What makes it puzzling is that good error handling and error messages aren't particularly difficult to do with typical business applications.  They aren't typically dealing with low-level functions like CPU instructions, hardware drivers, or low level network connectivity, so there aren't too many excuses for not having decent error handling.  It just takes a little bit of knowledge, some basic design practices, consistent coding, and project management.  I'm confident the team that developed Management Reporter could easily improve the error messages if it were made a priority and a practice.

Users, customers, consultants and developers:  Demand better error messages.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com