Do you produce useful exception messages?

Here is a method for adding a new Employee to a database:

public void AddEmployee(AddEmployeeCommand command)
{
    var employee = factory.CreateEmployee(command);
    repository.Add(employee);
}

Here is the same method again, but this time we have vastly improved it, by adding some useful error messages:

public void AddEmployee(AddEmployeeCommand command)
{
    try
    {
        var employee = factory.CreateEmployee(command);
        repository.Add(employee);
    }
    catch (Exception e)
    {
        var message = String.Format("Error adding Employee '{0}'", 
            command.EmployeeName);
        throw new Exception(message, e);
    }
}

Why is this such a vast improvement? Good error messages won’t help deliver features faster or make your tests green. But they will make your life a hell of a lot easier when things start to go wrong.

One recent example where I used this was in a system where we had to constructing a big hierarchical object graph of all the training statuses of employees in a geographical area. When we got an error, it looked like this:

Error generating Training report for 'Canterbury' district.
--> Error generating report for 'Christchurch' team.
   --> Error generating report for Employee 'Richard Dingwall' (#3463)
      --> Error getting Skill 'First Aid' (#12)
         --> SQL error in 'SELECT * FROM ...'

Error messages like this make it very easy to pinpoint problems, than if we had just a raw invalid identifier ADO.NET exception. Its like wrapping an onion — each layer adds a bit more context that explains what is going on.

Now, you don’t need to add try/catch blocks to every method in your call stack, just important ones like entry points for controllers and services, which mark the boundary of key areas in your application.

Exception messages should tell us two things:

  1. What was the action that failed?
  2. Which objects were involved? Names, IDs (ideally both), filenames, etc

When adding exception messages, first target areas that deal with external interfaces, because they are the places most likely to cause headaches through bugs or misconfiguration: databases, files, config, third-party systems etc.

Providing good exception messages is essential for making your application easy to maintain — easy for developers to quickly debug, and easy for system administrators to resolve configuration issues.

Remember, there is nothing more infuriating than getting a NullReferenceException from a third-party library.

8 thoughts on “Do you produce useful exception messages?

  1. Agreed, though FxCop will flag your modified AddEmployee method since you are both catching and throwing Exception instead of a more specific exception.

  2. Pedro: yeah, that’s true, but I think it’s okay in this case — the rule “catch specific exceptions” (not just blanket any Exception) relates to behaviour (how you react to different sorts of exceptions), whereas this is purely for informational purposes.

    Although it would be nicer to throw a specific AddEmployeeException instead.

  3. Hi richard

    Just want to clarify with you,do you send command message to your domain,AFAIK command message is used in ApplicationService

  4. One more thing based on your experience practicing DDD, how do you handle a creation of object with many parameter.

    Do you use factory at ApplicationService level?

  5. ryzam: factory pattern in domain (if domain-related) or application services (e.g. if creating based on a command). But beware, if you have too many parameters, it might be a sign that your object has too many responsibilities and needs to be split up.

  6. From example I have a uses case to register a LicenseCustomer and have capabilities of having many ImprestAccount, also ImprestAccount can have many License registered under it.

    Beside that when create ImprestAccount it also need to get ImprestAccountNumber, so the point here is there are many domain involve in one process for creation. I endup with creation of object at applicationservice level eventhough for License

Comments are closed.