Le 24/12/2010 02:24, Gilles Sadowski a écrit :
> 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".
OK, I missed that point.
Losing the inheritance from java.util.Format seems fair at Vector level,
so +1 from me.
Luc
>
>
> 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
