Posted by: jsonmez | June 23, 2010

Self-localizing Error Messages

Yesterday I ran into a problem trying to figure out where to localize error messages.

We are using a MVP (Model View Presenter) pattern for our web based application.  I was working on refactoring some code to move the business logic which handled the parsing of a file out of the view layer and down into the model.

When my file parsing class encounters errors, it needs to be able to send those errors back up to the view to be displayed to the user.

Since there could be multiple errors and we don’t necessarily want to stop parsing the file if we hit an error, we need a way to batch up those errors to be sent up to the presenter to give to the view.


It is easy enough to come up with a list of strings of error messages, until you consider the problem of localization.

Should the file parser really need to know anything about localization?  Should it even really deal with error message strings?

IErrorMessage to the rescue

Once I came across the solution, it was obvious to me.

Why not have the error message localize itself?  In fact, why not give the message the data it needs that is specific to that instance and let it construct itself?

It turns out to be a very clean solution.  The responsibilities are clearly separated.  Let’s take a look at the new flow.

  1. Presenter hands a data source to the file parser to parse.
  2. Parser begins parsing the file.
  3. When parser encounters an error, it creates a new typed error message which implements IErrorMessage.
  4. The list of error messages is returned to the presenter.
  5. The presenter loops through the list of error messages asking each one for its generated message.  (The presenter doesn’t know anything about localization here).
  6. The error messages use their internal data and localization to generate a localized error message for the presenter.
  7. The presenter passes the generated strings to the view.

Why all the hoopla?

Why not just localize the strings inside the file parser?

Good question.  It really boils down to separation of concerns and single responsibility.

Ideally we don’t want either the presenter or the parser to have to know anything about generating strings from bits of data and localizing those strings.

By doing this, we make the software easier to maintain and debug, since only one thing is happening in one place.

Want to change how the file is parsed?  Look in the file parser, error messages still handle generating their string representations, without you having to know how.

Want to change how an error message creates its string representation?  Just look at that error message class.

Not even the presenter needs to know about how error messages are formatted or generated, it just needs to know that it has some errors and it can tell the errors to give it a string representation.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.



  1. Excellent example of seperating duties. It also adds a great deal of reusability to your error handling code. Since your error class just needs a few pieces of data passed to it in the constructor and can raise an event when it is done, it will integrate nicely with whatever solution you stick it into. There are times when dividing the work up cleanly can generate a lot of extra code, but it is a trade off for future maintenance.

  2. […] Self-localizing Error Messages (John Sonmez) […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: