commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math] RealVectorFormat and ParseException
Date Fri, 24 Dec 2010 08:42:43 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


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


Mime
View raw message