Le 23/12/2010 14:31, Gilles Sadowski a écrit :
> 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.

So you basically prevent users from doing

  Format fmt = new RealVectorFormat();

Also if there is still a CompositeFormat inside which still extends
java.util.Format, what happens when it cannot parse ? Is the checked
exception caught and wrapped into an unchecked one ?

Luc

> 
> 
> Regards,
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to