Introduction
It was another non-memorable Friday when Sam entered the building. The place was deserted like any island resort on receiving a tsunami alert. Inside the entrance was a large hallway . At the end of the hallway was a large automated teller. He pressed the appropriate buttons and saw the following error, "E201a: Your money is not withdrawn yet since the end of this location is coming in the next ten minutes. Please wait."
This blog is about error messages and what can be done about them. Wikipedia defines an error message as " information displayed when an unexpected condition occurs, usually on a computer or other device."
This may be accompanied by a graphic that may or not be amusing.
Error Messages: The Current State
People do not like bad surprises such as crashes, slowness, freezing etc. with their software and hardware. Since nanites are not yet shipped with hardware/software, they are not yet self-correcting.
That means that we must rely on error messages that:
- Are terse
- Do not tell us what is happening/has happened
- Provide no steps on how to correct it
- Tell us where the error has taken place
- State the importance of the error message
- Whether or not it can be ignored
- Cannot provide historical context if this has happened before.
Given most of these appear in a pop up box, their level of detail is purposely limited.
As a result, you may search online or through a knowledge base for an answer. But knowing that error message may not give you the complete context as to what is happening. That is why Support people like full logs rather than snippets.
In some places in the code, there may be no error messages at all. So a special debug version may have to be created to get a better understanding as to what is taking place.
Error Messages: What Could be Done.
In addition to minimizing software exceptions, the following should be done.
- Provide an error guide or all or top 20 errors.
The former is done by Oracle and APM Agent Command Center. I expect this effort to be expanded for future APM features.
The latter is done also by APM see Troubleshooting common-errors and resolution
For Oracle and APM, the message has a taxonomy on the error number range and what each means. Each Number has a description, cause, and action. A description of the associated file is provided.
- Make errors highly visible AND readable.
In addition to the above, the exception handling should ideally:
- Capture logs at time of exception. Not doing this hampers support case resolution
- Not corrupt files
- Provide an undo feature
- Provide a simple way to resolve the issue
- Tie this to alerting & graphical performance system screen to view historical trends of this exception
I am making it a personal mission for 2016 to document as many error of the APM CE (CEM) messages as I can. Recently, I documented many of the previously published Transaction Discovery (autogen) Error messages
Other Knowledge Documents will follow.
I look forward to your comments on this topic
Other Sources:
Four H's of Writing Error Messages
Error Message Guidelines