You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by George Harley <ge...@googlemail.com> on 2006/05/10 20:07:10 UTC

[classlib] Exception throwing compatibility

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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
I think we should throw either what RI throws or a sub-class:
we will unlikely break existing apps and will have enough flexibility
to cover design issues mentioned in "[classlib] matching RI exceptions --
are we required to have this type of compatibility? " mail thread.

Thanks,
Mikhail

2006/5/11, George Harley <ge...@googlemail.com>:
> 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
>
>

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

Re: [classlib] Exception throwing compatibility

Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
 > 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 <ri...@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

Re: [classlib] Exception throwing compatibility

Posted by Stepan Mishura <st...@gmail.com>.
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();

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


-- 
Thanks,
Stepan Mishura
Intel Middleware Products Division

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

Re: [classlib] Exception throwing compatibility

Posted by Alexey Petrenko <al...@gmail.com>.
2006/5/12, Nathan Beyer <nb...@kc.rr.com>:
> What is the value in changing the 1 method that throws
> StringIndexOutOfBoundsException to ArrayIndexOutOfBoundsException?
The value is that possible user application depending on RI's
behaviour will work with ArrayIndexOutOfBoundsException but will fail
with StringIndexOutOfBoundsException

-- 
Alexey A. Petrenko
Intel Middleware Products Division

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/12, Nathan Beyer <nb...@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 <fi...@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 <ri...@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

Re: [classlib] Exception throwing compatibility

Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
<snip>
> 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?

I just wrote what I thought made best sense <g>.  Everyone should feel
free to suggest patches to the doc too.

I tried to capture the situation in the following sentence wrt exceptions:

"Harmony class library code should throw exceptions of the same type as
the RI, other than in cases where the RI throws non-public types
whereupon Harmony will throw an exception with the same public supertype."


Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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

Re: [classlib] Exception throwing compatibility

Posted by George Harley <ge...@googlemail.com>.
Chris Gray wrote:
> On Friday 12 May 2006 11:37, George Harley wrote:
>   
>> 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.
>>     
>
> Right, and in general we cannot know exactly which exception type the RI will 
> throw in any specific case - we have to start from the assumption that it 
> follows the spec, and take note of any deviations or more specific behaviour 
> that turns up. It's not possible to exhaustively test every exception case.
>   

Hi Chris,

Absolutely agree with you that we should not be looking to exhaustively 
test every exception case. We have to work in a mode where we respond to 
each deviation as we become aware of them.


>   
>> 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.
>>     
>
> If the app is written to the spec there's no problem. But in real life it can 
> happen that the developer doesn't look at the spec - during testing her code 
> throws an AIOOBE, so she adds an exception handler for that case. In this 
> case we make this (incorrect) app run by copying RI's behaviour (insofar as 
> we can determine what this is). But if RI throws 
> sun.util.FunnyIndexOutOfBoundsException and the programmer codes to this, 
> we're hosed - the app has to fixed.
>
> Chris
>   

Indeed. We can only throw something with the same 
public/non-implementation-specific supertype and hope for the best.

Best regards,
George


>
>   


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

Re: [classlib] Exception throwing compatibility

Posted by Chris Gray <ch...@kiffer.be>.
On Friday 12 May 2006 11:37, George Harley wrote:
> 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.

Right, and in general we cannot know exactly which exception type the RI will 
throw in any specific case - we have to start from the assumption that it 
follows the spec, and take note of any deviations or more specific behaviour 
that turns up. It's not possible to exhaustively test every exception case.

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

If the app is written to the spec there's no problem. But in real life it can 
happen that the developer doesn't look at the spec - during testing her code 
throws an AIOOBE, so she adds an exception handler for that case. In this 
case we make this (incorrect) app run by copying RI's behaviour (insofar as 
we can determine what this is). But if RI throws 
sun.util.FunnyIndexOutOfBoundsException and the programmer codes to this, 
we're hosed - the app has to fixed.

Chris


-- 
Chris Gray        /k/ Embedded Java Solutions      BE0503765045
Embedded & Mobile Java, OSGi    http://www.k-embedded-java.com/
chris.gray@kiffer.be                             +32 3 216 0369


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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
Hi George,

2006/5/12, George Harley <ge...@googlemail.com>:
> Mikhail Loenko wrote:
> > 2006/5/12, George Harley <ge...@googlemail.com>:
> >> 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.
> >
> > -1
> >
> > Do not see any reason to disallow throwing a subclass
> >
> > Thanks,
> > Mikhail
> >
>
> Hi Mikhail,
>
> Nor can I off the top of my head. So you are advocating something like
> "Harmony class library code should throw exceptions of the same runtime
> class (or a subtype of that runtime class) as the RI" ? Do you have in

Correct.


> mind a particular example of this in the current code base ?

We have a general discussion in the thread "[classlib] matching RI exceptions
-- are we required to have this type of compatibility? "

I can recall a specific example:
Most of the methods that use ASN.1 functionality declared to throw IOE

If some decoding errors occur we might:
- throw IOE
- throw dedicated ASN1Exception extending IOE
- throw ASN1E in decoder, then catch it in a public API method and convert to
IOE

Our implementation throws ASN1Exception extending IOE every time
ASN.1 error occurs. As far as there might be future classes such that RI throws
different exception (not an IOE) we keep possibility to catch ASN1 and wrap it
into another exception in certain rare cases.

Thanks,
Mikhail

>
> Best regards,
> George
>
>
> >
> >>
> >> Best regards,
> >> George
> >
> > ---------------------------------------------------------------------
> > 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

Re: [classlib] Exception throwing compatibility

Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> 2006/5/12, George Harley <ge...@googlemail.com>:
>> 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.
>
> -1
>
> Do not see any reason to disallow throwing a subclass
>
> Thanks,
> Mikhail
>

Hi Mikhail,

Nor can I off the top of my head. So you are advocating something like 
"Harmony class library code should throw exceptions of the same runtime 
class (or a subtype of that runtime class) as the RI" ? Do you have in 
mind a particular example of this in the current code base ?

Best regards,
George


>
>>
>> Best regards,
>> George
>
> ---------------------------------------------------------------------
> 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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/12, George Harley <ge...@googlemail.com>:
> 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.

-1

Do not see any reason to disallow throwing a subclass

Thanks,
Mikhail


>
> Best regards,
> George

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

Re: [classlib] Exception throwing compatibility

Posted by George Harley <ge...@googlemail.com>.
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 <fi...@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 <ri...@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

RE: [classlib] Exception throwing compatibility

Posted by Nathan Beyer <nb...@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
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 <fi...@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 <ri...@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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/12, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > 2006/5/12, Jimmy, Jing Lv <fi...@gmail.com>:
> <snip>
>
> >> 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
>
> Each project guidelines is just a proposal until we have thrashed it out
> on this list.  I tried to capture the dev list discussions up to that
> point so we could debate a concrete document.
>
> Talking of which, please can you mark the testing conventions[1] as
> proposed until we reach consensus?

OK, sure. BTW, nobody still proposed any alternative.

Sorry for off-topic,
Mikhail

>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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

Re: [classlib] Exception throwing compatibility

Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> 2006/5/12, Jimmy, Jing Lv <fi...@gmail.com>:
<snip>

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

Each project guidelines is just a proposal until we have thrashed it out
on this list.  I tried to capture the dev list discussions up to that
point so we could debate a concrete document.

Talking of which, please can you mark the testing conventions[1] as
proposed until we reach consensus?

[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/12, Jimmy, Jing Lv <fi...@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 <ri...@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

Re: [classlib] Exception throwing compatibility

Posted by "Jimmy, Jing Lv" <fi...@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.

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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Fursov <mi...@gmail.com>.
I agree that the easiest way for us is to throw RI or subclass.

Is it 'bad' practice to fix this "bug" (replace subclass with RI)  on user
request and do not think about this problem today?

On 5/11/06, Richard Liang <ri...@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
>
>

Re: [classlib] Exception throwing compatibility

Posted by Richard Liang <ri...@gmail.com>.
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

Re: [classlib] Exception throwing compatibility

Posted by Chris Gray <ch...@kiffer.be>.
Hi,

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

Dmitry is wrong.

> * Nathan believes that the code already abides by the specification and
> that there is no need for any change in this area.

Nathan is right.

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

You are right too. If it were my project I would change to mimic the RI once 
the discrepancy were pointed out to me, but I wouldn't (and don't) go looking 
for such things.

Chris

-- 
Chris Gray        /k/ Embedded Java Solutions      BE0503765045
Embedded & Mobile Java, OSGi    http://www.k-embedded-java.com/
chris.gray@kiffer.be                             +32 3 216 0369


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

Re: [classlib] Exception throwing compatibility

Posted by Alexey Petrenko <al...@gmail.com>.
I agree with George and Mikhail that we should throw the same exception with RI.
Do not forget about developers who expects this behaviour. If their
application works OK on RI and fails with
StringIndexOutOfBoundsException on Harmony they will probably return
to RI. Everybody is lazy and do not want to fix their code :)

2006/5/10, George Harley <ge...@googlemail.com>:
> 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
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division

Re: [classlib] Exception throwing compatibility

Posted by Andrew Zhang <zh...@gmail.com>.
Hi, George

I agree with your point.

Harmony should throw the same type exception as RI unless we  have
sufficient reason such as RI conflict with spec,

or RI's behaviour is illogical or Harmony can't produce the same exception
as RI.

On 5/11/06, George Harley <ge...@googlemail.com> 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.


-1. It violates compatibility, although both behaviours abide by spec.

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


+1

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


-- 
Andrew Zhang
China Software Development Lab, IBM

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
P.S. What if depending on the reason RI throws different subclass
of what is in the spec? Are we going to explore all possible combinations?

2006/5/11, Mikhail Loenko <ml...@gmail.com>:
> What is the reason for prohibiting throwing a sub-class?
>
> Every existing try... catch construction will work
>
> Do we really want to convert all tests like
> try {
>    do something
>    fail();
> } catch (SomeException e) {
>    //expected
> }
> to something like
> try {
>    do something
>    fail();
> } catch (SomeException e) {
>    assertEquals(SomeException.class, e.getClass());
> }
>
> Thanks,
> Mikhail
>
> 2006/5/11, Geir Magnusson Jr <ge...@pobox.com>:
> >
> >
> > George Harley wrote:
> >
> > >
> > > * 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".
> >
> > +1
> >
> >
> > ---------------------------------------------------------------------
> > 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

Re: [classlib] Exception throwing compatibility

Posted by Mikhail Loenko <ml...@gmail.com>.
What is the reason for prohibiting throwing a sub-class?

Every existing try... catch construction will work

Do we really want to convert all tests like
try {
    do something
    fail();
} catch (SomeException e) {
    //expected
}
to something like
try {
    do something
    fail();
} catch (SomeException e) {
    assertEquals(SomeException.class, e.getClass());
}

Thanks,
Mikhail

2006/5/11, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> George Harley wrote:
>
> >
> > * 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".
>
> +1
>
>
> ---------------------------------------------------------------------
> 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

Re: [classlib] Exception throwing compatibility

Posted by Geir Magnusson Jr <ge...@pobox.com>.

George Harley wrote:

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

+1


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