Those messages are **expected to be read by developers** to help them debug the application. This can take two forms:

 - Active debugging. You're actually running a debugger while writing code and trying to figure out what happens. In this context, a helpful exception will guide you by making it easy to understand what's going wrong, or eventually suggesting a workaround (although this is optional).

 - Passive debugging. The code runs in production and fails. The exception is logged, but you only get the message and the stack trace. In this context, a helpful exception message will help you quickly localize the bug.

   Since those messages are often logged, it's also means that you shouldn't include sensitive information there (such as private keys or passwords, even if it could be useful to debug the app).

**End users are not expected to see exception messages. Never.** Although some developers end up showing those messages to the users, they ensure by that poor user experience and frustration. The fact that there is a *null reference* means absolutely nothing to an end user, and should be avoided at all costs.

Exception messages are **not expected to be parsed** or used programmatically either. If you think that additional information can be needed by the caller, include it in the exception side by side with the message.