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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> 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-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
