In my previous post, I mentioned that I was assisting a developer with an issue. It turned out that the issue he was having was not the cause of an error, but the result of a previous error that the users had not told him about. Once the original error was fixed, the entire problem was solved.
So, this raised an issue which is probably one of the most frustrating aspects of support a system that support engineers and consultants have to face on a day to day basis. So I will get up on my soapbox again to discuss this subject.
When an error or an exception occurs, the script that was running at the time is aborted and the execution stack is cleared.
This means that even though clicking OK could leave the system looking like everything is alright, the system is in fact in an unknown state. Changes to data in memory or tables might not have been completed, fields on the window might be incorrect.
If a user continues working after the error, any number of future errors could occur and there is also high risk of data corruption.
It is vitally important that a user reports the very first error that occurs as well as any subsequent errors and does not attempt to continue using the application without checking with their support people.
When an error is reported, they should include:
- List of actions leading up to error.
- Information on which data they were accessing at the time, ie. a particular customer, vendor or transaction, etc.
- Screenshots of each error message. If the error message is displayed in a window with scroll bars, make additional screenshots to ensure that all of the information is captured. If the dialog has details or more info button, click it and capture additional screenshots of the details provided.
While I don’t want to tell partners how to do their jobs, I do want to make sure that the importance of capturing the initial error message is passed onto the end users.