It is my opinion that software problems tend be analyzed corresponding to these four axes:
- Can an end-user solve the problem themselves? If so, tell them how, if not, display a generic error message telling them to ask for support (with an error identifier they can tell the support)
- Developers and end-users need different information: developers need as much information as possible, like file names, contents of important variables and especially where the error happened in the source code with a backtrace, sometimes even two backtraces: the backtrace for the cause of the error, too; and end-users only need to be told what they can do, but this needs to be worded clearly and carefully. This means that error messages need to be written twice.
- Is the problem serious? If so, report, crash and restart, if not, just report and abort the affected operation when neccessary.
- The problem should be logged. Sometimes it can be sent to developers automatically.
- Can an end-user solve the problem themselves? If so, tell them how, if not, display a generic error message telling them to ask for support (with an error identifier they can tell the support)
- Developers and end-users need different information: developers need as much information as possible, like file names, contents of important variables and especially where the error happened in the source code with a backtrace, sometimes even two backtraces: the backtrace for the cause of the error, too; and end-users only need to be told what they can do, but this needs to be worded clearly and carefully. This means that error messages need to be written twice.
- Is the problem serious? If so, report, crash and restart, if not, just report and abort the affected operation when neccessary.
- The problem should be logged. Sometimes it can be sent to developers automatically.