Re: [i18n] Hardcoded message strings

[Alex Blewitt]

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 
better?

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("info.org.apache.geronimo.mail-authentication.failed")

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 
number.

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 ...

Alex.