Hello.
On Fri, 25 Dec 2015 10:31:43 +0100, Luc Maisonobe wrote:
Le 25/12/2015 04:46, Gilles a écrit :
On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:
[...]
When our users build a large application, they rely on numerous
different libraries and tools, both open-source and proprietary.
These libraries do have standard interfaces so they can be used
together. The Java standard library is one of them. the
getLocalizedMessage method is specified there. Many of the
libraries
and tolls user will assemble rely on it. Deciding that for the
sake
of Apache Commons Math we do not abide to this and decide that
all
other existing code should adapt to a different design is a clear
no go for me.
Does the JVM abide by this?
Yes,
Then, how to explain that the following code
---CUT---
for (Locale loc : new Locale[] { Locale.ENGLISH,
Locale.FRENCH }) {
Locale.setDefault(loc);
System.out.println("Locale=" + loc);
try {
final int a = 2;
double r = a / 0;
} catch (Exception e) {
System.out.println("JVM toString(): " + e);
System.out.println("JVM getLocalizedMessage(): " +
e.getLocalizedMessage());
}
try {
throw new NotStrictlyPositiveException(-1);
} catch (Exception e) {
System.out.println("CM -> toString(): " + e);
System.out.println("CM -> getLocalizedMessage(): " +
e.getLocalizedMessage());
}
}
---CUT---
produces this output:
---CUT---
Locale=en
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString():
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
is
smaller than, or equal to, the minimum (0)
CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the
minimum (0)
Locale=fr
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString():
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
n'est pas strictement plus grand que le minimum (0)
CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que
le
minimum (0)
---CUT---
?
I'm confused. If instead of the division by zero I try to open an
inexistent file, the message is translated in French. This is why I
assumed it was properly handled. However, it is also translated using
the regular getMessage(). So I guess the translated message is
provided
at lower level by the operating system (Linux in my case) which uses
the LANG environment variable and does not follow the
setDefaultLocale
setting.
I'm not jumping to any conclusion, but I think that this should at
least
let everyone be open to questioning the correctness of having
localization
performed inside CM.
The following page illustrates an approach similar to the one advocated
by Ole and me (i.e. externalize the translation service):
http://www.onjava.com/pub/a/onjava/excerpt/javaexIAN3_chap8/index1.html?page=2
It's interesting on (at least) two accounts:
1. Error handling policy of the user might require more than offered by
the libraries it uses.
That is if CM offers "internal" localization, a user will still have
to
try/catch in order to perform all the steps (e.g. logging as Ole
wrote).
2. It is half-baked IMO: Look at the bottom of the page to see what Ole
and
I were pointing out (mix and match of languages is arguably worse
than
no localization).
The behaviour of the JVM illustrated above shows that there is no way
to
justify an obligation to _perform_ localization of exceptions.
I fully agree that the existence of "Throwable#getLocalizedMessage()"
is a
hint that libraries should provide a way to _help_ performing
localization.
I think that "getPattern()" which you requested (or "getType()" in
Ole's
new design) fulfills that role. But there should probably end the
obligation
of CM.
[Looking at it objectively: I hope that if the feature had not existed,
we
would have turned it down like we did with other things deemed not
related
to the core purpose of CM.]
The localizing code is nice now ;-).
It's a fine utility, just that it should be an illustration, or a tool
provided in a separate JAR).
Best,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
