harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [classlib] Exception throwing compatibility
Date Fri, 12 May 2006 06:47:53 GMT
 > Stepan Mishura wrote:
> On 5/12/06, Jimmy, Jing Lv wrote:
>>
>> > Mikhail Fursov wrote:
>> > I agree that the easiest way for us is to throw RI or subclass.
>>
>> +1.
>>
>> >
>> > Is it 'bad' practice to fix this "bug" (replace subclass with RI)  on
>> user
>> > request and do not think about this problem today?
>> >
>>
>> In this case, though replace StringIndexOutOfBoundsException with
>> ArrayIndexOutOfBoundsException is surely better, it seems it is internal
>> implementation what cause the problem. According to the code it use
>> String.valueof(str), which writes:
>> try {
>>        System.arraycopy(data, start, value, 0, count);
>> } catch (IndexOutOfBoundsException e) {
>>        throw new StringIndexOutOfBoundsException();
>> }
> 
> 
> IMHO this try-catch block is redandunt - the method code already contains
> checks to verify that all parameters are valid:
> if (start >= 0 && 0 <= length && length <= data.length - start)
{
>   ....
> else
>    throw new StringIndexOutOfBoundsException();
> 

I believe you are right, but there may be some reasons for the author 
to write such try{...}catch(){}, perhaps he do follow RI's exception in 
the class String.

> Is it right to StringIndexOutOfBoundsException in String.valueof()? Then
>> to fix this, we shall write another
>> try{ ...
>> }catch(StringIndexOutOfBoundsException){
>>        throw new ArrayIndexOutOfBoundsException();
>> }
>> It is not so beautiful...
> 
> 
> Hmm, there is also no need in try-catch block, so the code should looks 
> like
> the following:
> if( parameters are invalid ){
>    throw new ArrayIndexOutOfBoundsException();
> }
> return append(String.valueof(........));
> 
> Thanks,
> Stepan.
> 
> 
>> However according to
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html 
>>
>> it has already draw a conclusion that:
>> 1) throw according to spec
>> 2) when we discover RI throw difference exception which is not internal
>> class, follow RI.
>>
>> What real matters is how can developers know what RI throws exactly in
>> all situations? Maybe a possible solution is that we fix one by one only
>> when we find the difference.
>>
>> > On 5/11/06, Richard Liang <richard.liangyx@gmail.com> wrote:
>> >>
>> >> George Harley wrote:
>> >> > Hi,
>> >> >
>> >> > I would like to start a little discussion around JIRA issue 436 [1]
>> >> > which deals with exception throwing compatibility between Harmony 
>> and
>> >> > the RI. I feel it is important to reach a concrete agreement on this
>> >> > as so far all of the participants in the issue seem to disagree 
>> about
>> >> > the interpretation of the compatibility guidelines on our web site
>> [2].
>> >> >
>> >> > You can read the discussion for yourself on the JIRA page (it is 
>> only
>> >> > a handful of comments) but if you are pressed for time the 
>> essentials
>> >> > are this (IMHO - Nathan and Dmitry please feel free to fill in the
>> >> > gaps) :
>> >> >
>> >> > * Currently the Harmony implementation of a few public methods in
>> >> > StringBuffer and StringBuilder throw different runtime exceptions
>> from
>> >> > the RI under certain failure scenarios.
>> >> >
>> >> > * Where the Javadoc mentions the exception type that ought to be
>> >> > thrown it mentions a type (j.l.IndexOutOfBoundsException) but the
>> >> > Harmony and RI implementations differ in that they are throwing
>> >> > different *sub-types* of j.l.IndexOutOfBoundsException. The RI tends
>> >> > to throw j.l.ArrayIndexOutOfBoundsException while Harmony tends to
>> >> > throw j.l.StringIndexOutOfBoundsException.
>> >> >
>> >> > * Dmitry (who raised the issue) believes that we should change the
>> >> > Harmony code to throw the type named in the Javadoc/specification
>> >> > (i.e. the supertype j.l.IndexOutOfBoundsException).
>> >> >
>> >> > * Nathan believes that the code already abides by the specification
>> >> > and that there is no need for any change in this area.
>> >> >
>> >> > * Little old me thinks that there *is* a problem here but that the
>> >> > solution is to do as the RI does and throw exceptions with the very
>> >> > same runtime type as the RI. That's based on my interpretation of 
>> the
>> >> > exception-throwing compatibility guidelines [2], in particular the
>> >> > fragment "Harmony class library code should throw exceptions of the
>> >> > same type as the RI".
>> >> >
>> >> >
>> >> > If I recall correctly we did agree to discuss such compatibility
>> >> > matters on a case-by-case basis. So, dear reader, what do you think
>> is
>> >> > the correct course of action in this case ?
>> >> >
>> >> > Best regards,
>> >> > George
>> >> >
>> >> >
>> >> > [1] http://issues.apache.org/jira/browse/HARMONY-436
>> >> > [2]
>> >> >
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html 
>>
>> >>
>> >> >
>> >> >
>> >> > 
>> ---------------------------------------------------------------------
>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >> >
>> >> Hello,
>> >>
>> >> Let me support Mikhail "we should throw either what RI throws or a
>> >> sub-class".
>> >>
>> >> --
>> >> Richard Liang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>>
>> -- 
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message