On Mar 17, 2010, at 4:24 AM, Emmanuel Lecharny wrote:
Hi guys,
Felix has done a tremendous work extracting all the error messages
from the code and gathering them in a sub project (shared-i18n and
apacheds-i18n).
This is just great, but I think we should go a bit further. If we
want to add a new error message, we have to add a new number at the
end of the list. As all the numbers start from 1 and are
incremented, it becomes rapidly difficult to group errors by their
numbers (ie, all the errors between 450 and 460 are related to
operation X).
What about defining a number which would inform immediately about
the kind of message we are dealing with ? We can for instance use
hex numbers, where the two higher bits will be used to indicate the
log level :
DEBUG = 00XXXXXXXXX...
INFO = 01XXXXXXXXX...
WARN = 10XXXXXXXXX...
ERROR = 11XXXXXXXXX...
The idea is that if the number is <0, then it's an error or a warning.
IN the same vein, we can also split the errors by family. As the
number will be an integer, it remains 30 bits to store informations.
Assuming that shared messages are indicated by the bit number 29,
then we have a way to split again :
101xxxxxx = a warning in the shared module
1111xxxxx = an error in the shared module, asn1 subproject...
etc.
wdyt ?
I have a fair bit of experience in this area and would recommend
against using numbers. It adds no value, one never needs to know the
log level of a message when translating, and is an impediment to
translation and understanding the code. Here's an example that proves
my point:
log.error( I18n.err( I18n.ERR_122 ), ioe );
That doesn't seem very helpful. Would this not be better?
log.error( I18n.err( I18n.errorEncodingEncryptionKey ), ioe );
If I am reviewing/translating the i18n files
ERR_122=Störungskodierung EncryptionKey
is not as easy to read and fact check as
errorEncodingEncryptionKey=Störungskodierung EncryptionKey
Finally the set of static strings in the I18n.java file are redundant
and don't really add any safety per se. As a matter of fact things
become a bit more brittle and are morally equivalent to using ints
instead of enums. I might make these enums whose values become
indexes to the resource bundle; this way you get type safety and can
use your IDE to see who uses the message.
Just my 2 cents.
Regards,
Alan
