Hello.
While replacing, in "RealVectorFormat", the last occurrence of the old
"o.a.c.math.MathRuntimeException" in package "linear", I stumbled upon the
following:
1. "RealVectorFormat" inherits from the standard Java class "Format".
2. That "Format" class has a method
public Object parseObject(String source) throws ParseException
where "ParseException" is a _checked_ exception.
3. Some unit tests for "RealVectorFormat" call that base class method,
although the actual parsing code (in "RealVectorFormat") never generates
that exception.
[Side-note: the old to-be-deprecated "MathRuntimeException" contains a method
public static ParseException createParseException(...)
Thus, we had the inconsistency that a class dedicated to creating unchecked
exceptions has a method that create a checked exception!]
We can solve the problem with the unit tests by readily calling the "parse"
method in the "RealVectorFormat" (instead of "parseObject" in "Format").
Then when "RealVectorFormat" fails to parse a string, it should throw a new
(not yet existing) "MathParseException" that will inherit from the new
"o.a.c.math.exception.MathRuntimeException".
But that will lead to the problem that some user could write
Format fmt = new RealVectorFormat();
at which point he has only access to "parseObject". He is thus obliged
to enclose the call in try/catch block and will be tempted to feel safe by
catching "ParseException":
try {
ArrayRealVector v = (ArrayRealVector) fmt.parseObject(str);
} catch (ParseException e) {
// Do something...
}
But the catch is actually useless because a failed parsing will throw a
"MathParseException" runtime exception!
To avoid this case, I was wondering whether we could, instead of having
public class RealVectorFormat extends CompositeFormat {
// ...
}
have
public class RealVectorFormat {
CompositeFormat compositeFormat;
// ...
}
without any ill side-effects.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
