I’ve been looking into incorporating Error Codes in the application I currently support, and I had some general questions.
The reason I am leaning towards using codes at all is because we have identified at least one serious issue in our application that is beyond our control to fix programmatically. The issue is very rare, but if it occurs it could cause severe downtime to the user. To fix it requires direct contact with support personnel who is familiar with the issue.
To do the best we can with it in the application, we are writing information to the Windows Event Log to point the support-staff to the corrupted data, and also display a generic “Please Call Support” prompt to the user.
We would like to add error codes to allow support to find the specific error in the Event Viewer more quickly.
So, first question: Is this an acceptable approach, or is there another idea I haven’t considered?
Second, if we use Error Codes, what’s the best way to manage them in our solution? Include an error-code-file in each project with non-intersecting integer-groups blocked out (yuck)? Create a new project specifically for holding error codes (yuck)?
I’ve never had a good idea how Error Codes are best managed, and no two projects I’ve worked on have done it in any clean way. I’d prefer to avoid them, but if I do have to use them, I’d like to know what works best.
Error codes just exist as a way to succinctly describe every known possible error scenario – as a way of ensuring that localisation and Chinese-whispers don’t confound any troubleshooting process.
Assuming you have a unique human-readable error message for each and every error condition, then you don’t need to maintain a database of error codes, just compute it as a hash of the canonical English string (I assume that’s your default language). If you add localised versions then just keep on using the English string as the basis of the digests.
When you receive a tech call you just need to find the string that matches the hash code, which is something that can be done automatically with a utility program (Reflection to the rescue).
Alternatively, ensure all exceptions that are displayed to the user are encapsulated by your own Exception subclass that has a required error-code constructor argument which becomes the responsibility of the developer.