In a post to his site Ross Tuck shares some of his experience and some helpful hints around formatting exception messages and how doing so effectively can make life for fellow developers much easier.

Over the last couple years, I’ve started putting my Exception messages inside static methods on custom exception classes. This is hardly a new trick, Doctrine’s been doing it for the better part of a decade. Still, many folks are surprised by it, so this article explains the how and why.

He shares his tips as a part of a "refactoring" in a simple example, a CSV import where there are failures during the import process on certain lines. He starts with the basic Exception and works through the logic to customize it and make it more useful. He shows the inclusion of additional details in the message, abstracting out the formatting to custom methods based on the error type and using static methods for the more complex message formatting. He also suggests the creation of methods to handle specific error cases with more details than a simple single-line error in a normal exception being thrown.

When you co-locate the messages inside the exception, however, you gain an overview of the error cases. If these cases multiply too fast or diverge significantly, it’s a strong smell to split the exception class and create a better API. [...] Sometimes we underestimate the little things that shape our code. [...] Creating good environments at a high level starts with encouraging them at the lowest levels. Pay attention to what your habits encourage you to do.