Gilles Sadowski a écrit :
> Hello.
>
> I'd like to suggest that there could be a nicer way to handle localization
> of error messages. Please have a look at
> http://cal10n.qos.ch/
This looks promising, and I also considered developing a maven plugin
with some asm magic to help make sure all messages are translated
properly. However, I wanted to have a tool that would be only use at
build time.
>
> Of course, the first point that will be raised is that it creates an
> external dependency. Is this a "no-no" or, given some benefits, could it be
> acceptable?
The runtime dependency is a no-no (at least from me). Is it possible to
use only the build part and not the runtime part ?
>
> Basically, I think that dealing with strings inside the math library code is
> ugly and error-prone. E.g.
>
> throw MathRuntimeException.createIllegalArgumentException("{0} out of [{1},
> {2}] range",
> x, xval[0],
> xval[xval.length - 1]);
>
> A simple spelling mistake will defeat the purpose, as the localized version
> will not be found.
You are right.
> The above library takes care of this problem.
>
> Even so, I think that *messages* should not appear at this level. It is much
> simpler to use a set of specific exceptions. I.e. instead of the above
> statement, one would use:
>
> throw new OutOfRangeException(x, xval[0], xval[xval.length - 1]);
>
> where the exception is defined as
>
> public OutOfRangeException extends IllegalArgumentException {
> private double val, min, max;
>
> public OutOfRangeException(val, min, max) {
> this.val = val;
> this.min = min;
> this.max = max;
> }
>
> public String getMessage() {
> // ... The string (or "enum" if using the "cal10n" library)
> // should appear at this level.
> }
> }
>
> Admittedly, this means creating a lot of exception classes; but the
> advantage is that they will allow more control.
Perhaps some intermediate solution with more exception classes than we
have but not one class for each message.
At least, I agree the messages should be defined only once.
Are there good localization framework with no runtime dependency
available somewhere ?
Luc
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
