Hello,
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 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.
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?
Cheers, Gianny
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 :-)
Alex.
_________________________________________________________________ Trouvez l'âme soeur sur MSN Rencontres ! http://g.msn.fr/FR1000/9551
