harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Semukhina, Elena V" <elena.v.semukh...@intel.com>
Subject RE: [classlib] Exception throwing compatibility
Date Fri, 12 May 2006 06:10:32 GMT
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...

 

I agree that throwing ArrayIndexOutOfBoundsException looks quite natural
and more informative when dealing with array arguments.

To have a "beautiful" fix, why don't you just write 

 

System.arraycopy(data, start, value, 0, count);

 

without trying to catch any exception and rethrow another one?
ArrayIndexOutOfBoundsException, if happened, would be thrown by
System.arraycopy().

 

As for HARMONY-436, I agree that RI's behaviour in cases 2)-4) looks
more natural than Harmony's but doubtful in cases 1) and 5). 

 

Thanks,

Elena

 

> 

>However according to

>http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.h
tml

>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.h
tml

>>> 

>>> >

>>> >

>>> >
---------------------------------------------------------------------

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message