geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: [i18n] Hardcoded message strings
Date Mon, 25 Aug 2003 14:25:41 GMT

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

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

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

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.

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.

Do you plan to go to this direction?


>>>This has the downside that it makes the code less easy to read (you can't 
>>>see the error messages in the code) but the upside that it makes the 
>>>resource files infinitely easier to maintain.
>>I don't see this as a downside. Once you start using format strings at all 
>>you can argue the indirection makes the code harder to read -  the fact 
>>you've consistently applied a naming scheme (one much like logging) 
>>doesn't make it worse.
>Or you could combine the best of both worlds :-)

Trouvez l'âme soeur sur MSN Rencontres !

View raw message