commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [math] Exception Design
Date Fri, 25 Dec 2015 15:34:26 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message