Luc Maisonobe wrote:
> 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 ?
>
+1 - if possible to use only at build time, OK, but...
>> 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.
Do you actually ever type existing message strings? I always just
cut and paste them; unless I need to create a new one. I agree that
it is a little bothersome, but the setup is at least straightforward
and not hard for new developers to learn.
>
> 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.
+1 - please lets not go down the path of
MoreStuffIWantToTellYouButCantUseAMessageException
What should be built into the hierarchy is what users might want to
catch and handle differentially. What should go in messages is
additional information that might be useful to human beings
analyzing logs or stack traces. Cleanly defined parameterized
messages can also make the intent of surrounding code clearer when
reviewing it and working with stack traces.
>
> At least, I agree the messages should be defined only once.
Here we all agree.
Phil
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
