Wow u just described fully and emaculated why this proposal was
rubbing me the wrong way. I did not have the time to run through a use
case to see clearly - thanks for doing this and commenting for all our
benefit.
No general mechanical procedure makes up for act thought for each
case. We have to watch for that here.
I agree with Alan on this one. Let's not further obfuscate our code.
BTW it's time for a thorough audit of error messages and log output
since these days many are complaining about false error and excessive
verbosity without clear meaning.
Sent from my iPho
On Mar 24, 2010, at 9:46 PM, "Alan D. Cabrera" <[email protected]>
wrote:
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
