harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: [classlib] Exception throwing compatibility
Date Fri, 12 May 2006 09:37:30 GMT
Nathan Beyer wrote:
> Note, the RI is NOT throwing ArrayIndexOutOfBoundsExceptions, it is just
> letting them happen via invalid array look ups, but in these cases, the
> specification is marked with an IndexOutOfBoundsException.
>
>   

Hi Nathan,

If we consider the RI as a "black box" whose internals should be 
completely hidden from us - a starting point that I think is important 
to all participants of this project (and their legal representatives) - 
then it does not matter *why* the RI is throwing the AIOOBE. It just does.


> For most methods in StringBuilder and StringBuffer, the specification
> specifically states StringIndexOutOfBoundsException. It's only on the rare
> occasion is the base class, IndexOutOfBoundsException specified.
> ArrayIndexOutOfBoundException is never mentioned. For example, the
> java.lang.StringBuilder.insert(int offset, char c) method [1]. This method
> states that IndexOutOfBoundsException is thrown if the offset is invalid,
> but every other 'insert' method on StringBuilder states that
> StringIndexOutOfBoundsException is thrown in this condition. There are 12
> 'insert' methods and 11 MUST throw StringIndexOutOfBoundException and 1 MUST
> throw IndexOutOfBoundsException. 
>
> What is the value in changing the 1 method that throws
> StringIndexOutOfBoundsException to ArrayIndexOutOfBoundsException? According
>   

Because it is throwing a type of IOOBE that conflicts with the RI ? If, 
in this instance, we code it to throw an AIOOBE then we are satisfying 
the spec (because an AIOOBE is a type of IOOBE) *and* satisfying the RI.

> to the compatibility guidelines, first and foremost we follow the
> specification. The documented exception (no pun intended) to this rule is
> when the specification is "silent ... [or] is clearly illogical". The
> specification is not silent in this case, nor is it illogical and the
> current code implements the specification.
>
>   

What will matter more to potential Harmony adopters ? Adherence to the 
spec or ease of transition of their apps from the RI to Harmony ? In 
this case we can satisfy the spec and enable runtime compatibility by 
throwing the identical concrete exception type.


> Am I interpreting the guidelines incorrectly? If not and there is still a
> urge to have this changed, then what would the suggested change to the
> guidelines be?
>
>   

It sounds like there are as many interpretations of the guidelines as 
their are correspondents on this topic :-)
My suggested change would be that we state that Harmony class library 
code should throw exceptions of the same runtime class as the RI. 

Best regards,
George

> BTW: The 'insert' methods on StringBuffer are specified exactly the same way
> 11 with SIOOBE and 1 with IOOBE.
>
> -Nathan
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html#insert(
> int,%20char)
>
>   
>> -----Original Message-----
>> From: Mikhail Loenko [mailto:mloenko@gmail.com]
>> Sent: Thursday, May 11, 2006 9:48 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] Exception throwing compatibility
>>
>> 2006/5/12, Jimmy, Jing Lv <firepure@gmail.com>:
>>     
>>>  > 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();
>>> }
>>> 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...
>>>
>>> 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.
>>>       
>> As I understand it is just a proposal
>>
>> Thanks,
>> Mikhail
>>
>>
>>
>>     
>>> 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
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> 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
>>     
>
>
> ---------------------------------------------------------------------
> 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
>
>
>   


---------------------------------------------------------------------
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