When errors come up, people using the application may not understand why or know how to troubleshoot / debug the problem. Error messages should be descriptive and thorough enough to not only say what went wrong but also guess at why it went wrong. For example, if a video stream could not be opened, is that because it is open elsewhere?
Looking beyond this more human-centered description of the issue and how to troubleshoot/resolve it, there might still be utility in a more technical explanation of what is wrong. This could be moved to a more detailed and secondary error message (UI having some sort of expandable section for the smaller more detailed technical message).
Alternatively the application can dump technical messages to a log file and forego the front end entirely. This should be handled in an asynchronous and append-only manner so that should the application crash the logs not be corrupted, lost, or destroyed.
When errors come up, people using the application may not understand why or know how to troubleshoot / debug the problem. Error messages should be descriptive and thorough enough to not only say what went wrong but also guess at why it went wrong. For example, if a video stream could not be opened, is that because it is open elsewhere?
Looking beyond this more human-centered description of the issue and how to troubleshoot/resolve it, there might still be utility in a more technical explanation of what is wrong. This could be moved to a more detailed and secondary error message (UI having some sort of expandable section for the smaller more detailed technical message).
Alternatively the application can dump technical messages to a log file and forego the front end entirely. This should be handled in an asynchronous and append-only manner so that should the application crash the logs not be corrupted, lost, or destroyed.