harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib] Exception throwing compatibility
Date Fri, 12 May 2006 05:42:21 GMT
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.

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

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?

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


Mime
View raw message