commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-361) Localization and Error Handling
Date Tue, 15 Jun 2010 11:34:23 GMT

    [ 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/dev@commons.apache.org/msg14570.html]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message