geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [i18n] Hardcoded message strings
Date Mon, 25 Aug 2003 14:58:52 GMT
On Monday, Aug 25, 2003, at 15:25 Europe/London, gianny DAMOUR wrote:

>> I think it would be a good idea to break down such labels as to the 
>> package that threw them. So you'd have info.o.a.g.mail.blah, 
>> err(or).o.a.g.mail.blah etc and so forth. I also think that a 
>> non-numeric code is advisable, so that it is easier for the (human) 
>> developer to understand the message:
> I tend to disagree with this one: if one puts in the labels the 
> package directory, then refactoring will become rather hard. Moreover, 
> by using the stacktrace of the exception, it is rather simple to 
> retrieve the source of the exception.

You are right; hard-coding package names does make it more difficult to 
refactor package names. However, we need to arrange for some kind of 
structure that mirrors the code base somehow, so that (hopefully) we 
can create a set of exception labels that don't clash across the board.

Do you disagree with non-numeric, though? IMHO text labels are more 
understandable than numbers.

I also followed up a post on this to suggest that instead of package 
names, what about organising them by module name instead. Would this be 

You also state that it's obvious where an exception was generated by 
its stacktrace. Yes, this is indeed true, but I was thinking of naming 
them so that it would be possible for a translator to know where the 
exception was generated, as opposed to a run-time exception being 
generated. For example:

org.apache.geronimo.mail.authFailed=Authentication against %{0} failed

gives you a much better idea of where to look for what 'authFailed' 
means (and where it's used) than

authFailed=Authentication against %{0} failed

which could (potentially) be used by any part of the code-base. 
Further, %{0} in JavaMail may be used to represent the name of a 
store/folder, whereas the same message may be used against a 
WebContainer with %{0} as the userid, and then translations giving rise 
to discrepancies such as:

authFailed=User %{0} cannot log in

which may look weird when printed as "JavaMail: AuthenticatIon Failed 
Exception: User alex cannot log in", especially if the reference was 
generated as per a password-change mechanism.

>> throw new 
>> I18NException("")
>> That way, it's easier to 'guess' what the message is than a number, 
>> which can be mistyped or may not mean anything.
> I agree: a simple number is rather hard to understand. Moreover, as 
> you have pointed, it is possible to provide a number, which has no 
> meaning. As a response to these two issues, one could use a type-safe 
> enumeration. This way, one enforces the centralization of the error 
> codes/messages.

Yes, numbers don't really help.

> This is a really great idea to define message keys via:
> <type of error><error number>.

I don't see that Exception '252' is any more/less readable than 'Info 
252'. Or do you mean something like 'Authentication Failed: 252' ? In 
which case, is there much benefit in listing the type and number, when 
only one is sufficient?

> Oracle uses this "pattern" for all its products. More accurately, the 
> key is something like this:
> <application identifier>-<error number>. What is really handy is their 
> "Error Messages" reference documentation, which lists all these > errors.

Yes, I was suggesting using (initially) packages, then modules as the 
<application identifier>, but again using the text string instead of a 

> This is my two cents.
> Now, I have a question: if one defines a sub-class for each "type of 
> error" or "application", then one can:
> - firstly remove from the key, the "type of error" or "application 
> identifier"; and
> - classify the exceptions, which is rather helpful to implement a last 
> resort handling mechanism.

You mention the word 'sub-class' here, which confuses me. Are you 
talking about Java sub-classes? Or are you talking about properties 
like java.mail, java.mail.smtp, java.mail.imap etc?

Can you explain what you mean a bit more by these points, and provide 
examples of what you're thinking? It's obviously late in the day (and 
I'm not allowed coffee at the moment) so I can't understand what you 
mean ...


View raw message