We should think of an universal standard for error messages, some of the points made in this document have caught of guard many times and should be standard practice for errors across all kinds of software.
What is appropriate for error messages in some software might not be appropriate in others. Think web servers vs compilers vs word processors, etc. What is appropriate depends on a lot of factors such as the expected users of the software and what level of the stack the software operates in. In this case I'm not convinced that a standard would be helpful.
Agreed, if we consider that errors have two kinds of users (the end user and the developer) we might be able to find common needs for both sides. The needs of the end user are probably harder to generalize (as they depend on the intended action) but even here there might be requirements that are always appropriate: e.g googlability.
For developers, needs probably revolve around being able to comprehend what logical situation resulted in the unexpected behaviour. Meaning that errors should give some sense of what internal state cause it to appear and where the input that formed this state came from.
I argue it isn't the message that confuse people, it is that at least for me I may not know where to catch exception AND provide the reason/error message. To me I find writing exception a doubtful exercise.
And maybe some unique id in form (application id, error id) like VS compilers do. This will make process of rewording error message less painful for users trying to google it and developers hesitating whether to improve bad wording that is known to confuse users.
In development, I am always in favor of clear, concise, and active language. These are fantastic points with great justifications attached. I really like the tricky words near the end.
