harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] Exception throwing compatibility
Date Fri, 12 May 2006 06:08:03 GMT
2006/5/12, Nathan Beyer <nbeyer@kc.rr.com>:
> 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

just a side note: seems like everyone has its own opinion
derived from the compatibility guidelines :)

Thanks,
Mikhail


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

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