I’ve been doing some maintenance work on some old code. And I think that most of my effort has gone into making the error messages better. If a piece if software is successful then it means its going to be used in a live environment. It also means its going to break at some point and at that point its going to be a lot easier for everyone if the error message it produces makes sense.

For example just the other day I came across this piece of code that loads a piece of XML

new XDocument(xml).Validate(_schema, (sender, e) => {
 throw new DomainException("XML configuration is invalid.");
});

When it broke it produced this error message

XML configuration is invalid.

Not really very much use. And its so simple to make the error message better, a small change to this.

new XDocument(xml).Validate(_schema, (sender, e) => {
 throw new DomainException(string.Format("XML configuration is invalid. {0}",e.Message),e.Exception);
});

Gives this as an error message.

XML configuration is invalid. The element 'Config' has invalid child element 'BadElement'.
List of possible elements expected: 'Start, End, Days, Overwrite, Discount'.

I know that I want to focus on the code “happy path”, however from past experience the quality of error messages is one of the major factors in how fast and easily defects can be corrected.