Hello.
> >
> > 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();
It's either this or "ParseException" must be part of CM's interface, which
contradicts the new policy that all exceptions generated by CM should
inherit from the new "MathRuntimeException".
> 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 ?
A checked exception will never be thrown because the method that throws it
(i.e. "parseOject(String)") is not used internally: "RealVectorFormat" only
uses "parseOject(String,ParsePosition)" which is not declared to throw a
"ParseException".
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
