commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Localization and Error Handling
Date Thu, 25 Mar 2010 12:23:39 GMT
Hi.

> > 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.

Could you explain, by examples, how you imagine the separation between
build time and run 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 ?

Maybe I'll understand this with the examples, but rigth now, I don't see how
it would be possible: localization is a runtime feature; so in order to
benefit from a library, it must (also) be a runtime dependency.
Let's say that the compile time part creates a "dictionary" structure, you'd
still need the runtime to access it. If you don't want the dependency,
you'll need to re-implement all the look-up code that access the
"dictionary" from its persistent format, with the danger that this format
can be subject to change without notice (as it is created by the build time
dependency which you accepted).

> > 
> > 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.
> 
> You are right.

OK. So even without deciding on the use of an external library, can we start
using "enum"s (in a way similar to what "cal10n" does)?

> > 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.

I didn't do an exhaustive search but it seems that there are a lot of
redundant message strings:

 "must have n >= 0 for binomial coefficient (n,k), got n = {0}"
 "must have n >= 0 for n!, got n = {0}"
 "brightness exponent should be positive or null, but got {0}"
 "number of microsphere elements must be positive, but got {0}"
 "polynomial degree must be positive: degree={0}"
 "upper bound must be positive ({0})"
 "length must be positive ({0})"
 "permutation k ({0}) must be positive"
 "invalid row dimension: {0} (must be positive)"
 "invalid column dimension: {0} (must be positive)"
 "initial capacity ({0}) is not positive"
 "index ({0}) is not positive"
 "window size must be positive ({0})"
 "element {0} is not positive: {1}"
 "mean must be positive ({0})"
 "degrees of freedom must be positive ({0})"
 "alpha must be positive ({0})"
 "beta must be positive ({0})"
 "number of successes must be non-negative ({0})"
 "standard deviation must be positive ({0})"
 "the Poisson mean must be positive ({0})"
 "invalid number of elements {0} (must be positive)"
 "invalid exponent {0} (must be positive)"
 "number of sample is not positive: {0}"

I think that all of these could be reduced to one or two exceptions.
Conceptually, the error is the same ("value should not be negative").
The message supposedly gives more information than that, but actually the
additional info is redundant with the line number that is part of the stack
trace: from it, it's straightforward to figure out which input is wrong; we
don't need the message to specify that it is "alpha" or "beta" or "mean" or
"degree" etc.

> At least, I agree the messages should be defined only once.
> 
> Are there good localization framework with no runtime dependency
> available somewhere ?

I didn't find one. [Same question as above: How is such a thing supposed to
work?]

Concerning localization itself, I think that it's not the business of a
low-level library.
IMHO, CM should only be using exception objects. The Javadoc of those
exception classes and the "@throws" clauses are the places where the users
(i.e. *application* developers) can find the meaning and circumstance of the
problem.
Now, if, for political reasons ;-), you want to help the users by providing
a localization framework, why couldn't we consider it as an "add-on"
higher-level *optional* feature requiring an external dependency?


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