Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Exceptional practices, Part 3

Use message catalogs for easy localization

By Brian Goetz, JavaWorld.com, 12/21/01

  • Print
  • Feedback
.
In Parts 1 and 2 of this series, I explored several ways in which exceptions could be used more effectively to deliver error-recovery information to the parties that need it -- other Java classes, developers, and users. In Part 3, I look at the oft-ignored problem of internationalization and a technique for simplifying internationalization: the use of message catalogs for storing message text.

Read the whole series on exception handling:



Part 1 emphasized that if two different exceptions could potentially have different error-recovery procedures, then they should be of different classes -- although perhaps derived from the same base class. You never want to be in the situation where you will be tempted to use the message text to differentiate between two different exceptions. The message text associated with exceptions is explanatory only and exclusively for the consumption of people, not code.

Don't build error messages by hand

While most developers agree that it's a bad idea to hard-code text strings inside program code, most of us do exactly this all the time. The following code fragment illustrates a common but undesirable technique of throwing an exception:

Listing 1. Build error messages by hand

  if (!file.exists()) {
    throw new ResourceException("Cannot find file " + file.getName());
  }


Despite the fact that you probably see this construct every day, this is a bad way to build error messages. The explanatory error text simply does not belong in the Java code; it should be retrieved from an external source. What happens when you want to localize this code for a foreign market? Someone will have to comb through all the source code, identifying all text strings that will be used to build exceptions. Then a translator will have to translate them all, and then you have to figure out how to maintain different versions of the same code for multiple markets. And you have to repeat this process for every release.

Even if you never plan to localize, there are other good reasons for removing error message text from code: Error messages can easily get out of sync with the documentation -- a developer might change an error message and forget to inform the documentation writer. Similarly, you might want to change the wording of all error messages of a certain type to make them more consistent, but since you must comb through all the sources to find all such error messages, you could easily miss one, resulting in inconsistent error messages.

Clearly, the source code is not the place for explanatory messages, which really are more closely related to documentation than to code. In fact, developers probably shouldn't even be writing error messages any more than they should be writing documentation. How many times have you seen error messages that are utterly incomprehensible except to the person who wrote the code? As long as the error messages live inside the source code, they will be created and owned by developers, often to the detriment of usability.

  • Print
  • Feedback

Resources
  • Read more JavaWorld articles by Brian Goetz: