[
https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878938#action_12878938
]
Gilles commented on MATH-361:
-----------------------------
{quote}
There is no tool I know of that does the checks I would like to add.
{quote}
"cal10n" comes with JUnit tests (and a Maven plugin, which I couldn't make
work, probably because of my lack of knowledge...) that check the consistency
of the localization files.
{quote}
Throwing localization away (read with an external framework) when it consists
in one interface and one enumerated class is adding lots of complexity for a
basic feature (CM is a math library, localization is important I think but it
is not the core of the library and should not be over-engineered)
{quote}
Localization is not important for CM. [It might be for some users; it may also
be a nuisance for others (cf. one of the examples I gave before: some scientist
uses a non-English locale for a text processing application, but still expects
the CM error messages to be in English). Selecting a "framework" at runtime
allows the user to plug in a "no-op" library that won't do any localization.
Admittedly, the CM code will be slightly more complex but all in all, it is
just some 3 or 4 classes with less than a dozen lines!]
And, as you say in the next point: CM is a low-level component; but, IMO,
localization is a high-level feature.
In my view, implementing CM's own localization code _is_ over-engineering,
because the alternative of grabbing an off-the-shelf component like "cal10n" is
_zero_ work.
Also, localization is, obviously, the core of "cal10n" so that the designer may
already have thoroughly thought about the problem and come up with the most
appropriate solution...
Finally, it is not because something is easy to do, that you should do it:
laziness is one of the virtues of programming ;-) in that it leads to
modularization and code re-use.
{quote}
Dependencies are a good thing for high level application or libraries and are a
very bad thing for low level components [...]
{quote}
Why?
{quote}
I don't agree we need a pluggable localization framework, we need simple
localization
{quote}
I warned before that it could be dangerous to assume what users will need, or
not, in the future...
{quote}
[...] cal10n does implement its own logic for finding resources and its own
parser for properties file [...]
{quote}
You caught me here... Although maybe not: what if he did this with good reason
(efficiency)? The guy is the author of Log4J and its successors. Theses tools
came when something similar already existed but (from what I've read) the new
design solved a few annoying things in the previous solutions.
All that being said, I again stress that localization is not my main point
here; then let's go back to "error handling" which, indeed, I want to be
_separate_ from the "localization" issue:
{quote}
trying to set up some more meaningful exception [...] is a completely separate
problem.
{quote}
To restate my previous question (about replacing literal strings with an
{{enum}}), what will be the programming interface for CM developers? Something
like this
{code}
throw new
MathRuntime.createIllegalArgumentException(LocalizedMessages.OUT_OF_RANGE, x,
xMin, xMax);
{code}
or something like that
{code}
throw new OutOfRangeException(x, xMin, XMax);
{code}
Do we agree on the second form? I.e.
* a stateful exception class (with accessors to the instance variables)
* inheriting (in this case) from {{IllegalArgumentException}}
* where all references to localization are completely encapsulated
Is so, then the rest of the discussion (on the best way to provide the
localization feature) is not high priority (and can be postponed), and I
absolutely don't mind that you implement your proposal in the meantime.
To summarize, my request would become that we implement a set of exception
classes (in a new "exception" package) from which we can pick appropriately and
use as easily as in the second example above.
> Localization and Error Handling
> -------------------------------
>
> Key: MATH-361
> URL: https://issues.apache.org/jira/browse/MATH-361
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 2.1
> Reporter: Gilles
> Priority: Minor
> Attachments: l10n.tar.gz, res.tar.gz
>
>
> This proposal aims at easing the handling of error during algorithms
> development, and also enhancing the flexibility of the error reporting
> (provide meaningful exception classes and run-time selection of the
> localization formatting).
> More details at
> [http://www.mail-archive.com/[email protected]/msg14570.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
