You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Jesse Wilson <je...@google.com> on 2009/11/14 00:19:48 UTC
Doubting exception priority compatibility
Harmony team,
I'm skeptical of the utility of being exception-priority compatible with the
RI. We have a wiki
page<http://wiki.apache.org/harmony/Exception-throwing_compatibility>
describes
our goals, but I don't think these are worth their costs.
Recently I broke tests by breaking exception priority on this code:
public int read(char[] buffer, int offset, int length) throws
IOException {
synchronized (lock) {
if (isClosed()) {
throw new IOException(Msg.getString("K005b")); //$NON-NLS-1$
}
if (offset < 0 || offset > buffer.length - length || length < 0)
{
throw new IndexOutOfBoundsException();
}
...
We have test coverage that asserts the RI's exact exception priority:
1. if offset is negative, an IndexOutOfBoundsException is thrown
2. if buffer is null, a NullPointerException is thrown
3. if length is negative, an IndexOutOfBoundsException is thrown
This is very compatible! But it ties our hands from making common sense
improvements. For example, we cannot cache the buffer length in a local
variable without disrupting exception priority. The following change
reorders #1 and #2::
...
*int bufferLength = buffer.length; // cache this in a local
variable*
if (offset < 0 || offset > bufferLength - length || length < 0)
{
throw new IndexOutOfBoundsException();
}
Nor can we save branching operations by using bitwise rather than logical
OR. The following change reorders #2 and #3:
...
if (*offset | length < 0* || offset > buffer.length - length) {
throw new IndexOutOfBoundsException();
}
I'm all for compatibility. But I don't believe it is in our best interest to
strive for this degree of compatibility with the RI. Trying to get this
level of compatibility takes engineering time away from more useful tasks.
The RI's exception priorities are generally undocumented, and therefore must
be reverse engineered in each case. It also requires significant effort to
write test coverage for exception priorities. Although I acknowledge that
much of this work has already been done, many additional APIs and revisions
are still ahead of us.
I don't think real-world applications depend on exception priorities. For
example, I'm highly skeptical that there are programs that only work on
platforms where the exceptions above are thrown with priority #1, #2, #3. I
don't think I've ever seen a program that catches IndexOutOfBoundsException.
In my experience applications catch either the common supertype
RuntimeException, or they don't catch at all.
Agree/disagree?
Re: Doubting exception priority compatibility
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Nov 17, 2009 at 12:13 PM, Joshua Bloch <jj...@google.com> wrote:
> I would argue that we are doing a better job of ensuring compatibility with
> the RI by *not* mandating the same exception priority on these exceptions.
> In the RI, they can (and do) change even in minor releases. Our tests are
> mandating compatibility with a random snapshot of the RI on an
> implementation detail that the RI maintainers consider unimportant. We are
> thus encouraging our users to depend on this implementation detail. That
> just doesn't make sense.
>
> Interestingly, Sun went so far as to *prohibit *specifying which exception
> is to be thrown if multiple exceptions apply, 8 years ago:
> http://bugs.sun.com/view_bug.do?bug_id=4462062 . They actually filed a bug
> to change some documentation that specified this implementation detail
The comments about the RI changing behavior between fix releases and
the referenced bug link have me inclined to agree with the concept of
not worrying about exception priority. I don't think that has any
major ramifications other than making it acceptable to organize code
such that it's simple and efficient when making changes and adjust the
tests accordingly.
In practical terms, I don't see this making an enormous difference -
the order in which most unchecked exceptions like NPE, IAE, CCE are
thrown is generally the most straight-forward implementation of a
method.
-Nathan
>
> Josh
>
> P.S. I would add several exceptions to Jesse's list including
> ClassCastException (common for sorted collections, and highly implementation
> dependent).
>
> On Tue, Nov 17, 2009 at 9:20 AM, Jesse Wilson <je...@google.com>wrote:
>
>> For better or for worse, Dalvik was changed long ago to ignore exception
>> priorities. We get exception messages for NPEs and save branches. The full
>> set of deltas are here:
>>
>>
>> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>>
>> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>> >
>> > I don't argue changing exception order for a particular case if the
>> > change improves code simplicity and gives performance benefit on
>> > important real load, e.g. the change improved Eclipse startup time by
>> > 4%.
>> >
>>
>> I think the primary difference in our thinking is how much we value
>> exception priority consistency. I don't believe it has any value and
>> therefore we're imposing an unnecessary constraint on our code. Does anyone
>> have a real world example, (perhaps a bugreport) demonstrating where
>> exception priority incompatibility has caused grief?
>>
>
Re: Doubting exception priority compatibility
Posted by Joshua Bloch <jj...@google.com>.
I would argue that we are doing a better job of ensuring compatibility with
the RI by *not* mandating the same exception priority on these exceptions.
In the RI, they can (and do) change even in minor releases. Our tests are
mandating compatibility with a random snapshot of the RI on an
implementation detail that the RI maintainers consider unimportant. We are
thus encouraging our users to depend on this implementation detail. That
just doesn't make sense.
Interestingly, Sun went so far as to *prohibit *specifying which exception
is to be thrown if multiple exceptions apply, 8 years ago:
http://bugs.sun.com/view_bug.do?bug_id=4462062 . They actually filed a bug
to change some documentation that specified this implementation detail
Josh
P.S. I would add several exceptions to Jesse's list including
ClassCastException (common for sorted collections, and highly implementation
dependent).
On Tue, Nov 17, 2009 at 9:20 AM, Jesse Wilson <je...@google.com>wrote:
> For better or for worse, Dalvik was changed long ago to ignore exception
> priorities. We get exception messages for NPEs and save branches. The full
> set of deltas are here:
>
>
> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>
> 2009/11/17 Alexei Fedotov <al...@gmail.com>
> >
> > I don't argue changing exception order for a particular case if the
> > change improves code simplicity and gives performance benefit on
> > important real load, e.g. the change improved Eclipse startup time by
> > 4%.
> >
>
> I think the primary difference in our thinking is how much we value
> exception priority consistency. I don't believe it has any value and
> therefore we're imposing an unnecessary constraint on our code. Does anyone
> have a real world example, (perhaps a bugreport) demonstrating where
> exception priority incompatibility has caused grief?
>
Re: Doubting exception priority compatibility
Posted by Tim Ellison <t....@gmail.com>.
On 18/Nov/2009 17:29, Jesse Wilson wrote:
> On Wed, Nov 18, 2009 at 8:47 AM, Nathan Beyer <nd...@apache.org> wrote:
>
>> I haven't browsed the code either, but I don't believe viewing this
>> code would kick in additional restrictions. If that's true, then Jesse
>> and other Android folks wouldn't be able to contribute much of
>> anything.
>>
>
> Yeah, not being able to read my own source code would be a major drag.
lol - in this case there is no issue, since the Android code is
available under the ALv2.
Regards,
Tim
Re: Doubting exception priority compatibility
Posted by Jesse Wilson <je...@google.com>.
On Wed, Nov 18, 2009 at 8:47 AM, Nathan Beyer <nd...@apache.org> wrote:
> I haven't browsed the code either, but I don't believe viewing this
> code would kick in additional restrictions. If that's true, then Jesse
> and other Android folks wouldn't be able to contribute much of
> anything.
>
Yeah, not being able to read my own source code would be a major drag.
Re: Doubting exception priority compatibility
Posted by Nathan Beyer <nd...@apache.org>.
2009/11/18 Alexei Fedotov <al...@gmail.com>:
> Hello Jesse,
>
> Your link points to Google code which I cannot probably browse due to
> ACQ restrictions.
I haven't browsed the code either, but I don't believe viewing this
code would kick in additional restrictions. If that's true, then Jesse
and other Android folks wouldn't be able to contribute much of
anything.
> Anyway, I guess from your message that Google for
> the sake of user friendliness added messages to NPE exceptions, thus
> changing the exception order. I accept usability motivation for
> proposed wiki change. The motivation still have to be compared with
> performance motivation when NPE are quickly thrown by means of
> hardware interrupt without any message.
>
> Generally I find usability more important than performance. As for
> exception messages, I like them only when they add some vital
> information for a programmer, otherwise they just make information
> retrieval more challenging. From the other side, there likely exist
> people who benefit from exception messages if they are localized.
>
> As for dropping tests, I'm stil not convinced. Why not to fix tests
> instead? We have to be continuously improving.
>
> P.S. Concerning your question, I faced a problem with
> SecurityException testing getCertificates() behavior when worked with
> [1]. I added many non- specification asserts to the tests to
> understand when SecurityException should be thrown and be somehow
> compatible. My JIRA does not reference this problem, though extra
> asserts can be located in the patch to the unit test. Later we got a
> related bug report [2] concerning the implementation.
>
> P.P.S. I was looking for a JIRA issue which references a user
> applciation fail due to exception order and failed. I have found the
> author of the automatic tool instead [3]. I think it worth listen to
> him.
>
> [1] https://issues.apache.org/jira/browse/HARMONY-4569
> [2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
> [3] https://issues.apache.org/jira/browse/HARMONY-325
>
>
>
> On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <je...@google.com> wrote:
>> For better or for worse, Dalvik was changed long ago to ignore exception
>> priorities. We get exception messages for NPEs and save branches. The full
>> set of deltas are here:
>>
>> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>>
>> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>>>
>>> I don't argue changing exception order for a particular case if the
>>> change improves code simplicity and gives performance benefit on
>>> important real load, e.g. the change improved Eclipse startup time by
>>> 4%.
>>>
>>
>> I think the primary difference in our thinking is how much we value
>> exception priority consistency. I don't believe it has any value and
>> therefore we're imposing an unnecessary constraint on our code. Does anyone
>> have a real world example, (perhaps a bugreport) demonstrating where
>> exception priority incompatibility has caused grief?
>>
>
>
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://www.telecom-express.ru/
> http://harmony.apache.org/
> http://www.expressaas.com/
> http://openmeetings.googlecode.com/
>
Re: Doubting exception priority compatibility
Posted by Tim Ellison <t....@gmail.com>.
On 18/Nov/2009 18:32, Alexei Fedotov wrote:
> One more thing about fixing tests. Ok, the exception order should not
> be tested. But the method still should be invoked (giving the same
> code coverage), and the method result (exception) should be checked in
> a less rigorous way, e.g. it should be a runtime exception.
Yep, I hope we all agree that testing error conditions is still useful.
Such tests would be updated not removed.
Regards,
Tim
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
One more thing about fixing tests. Ok, the exception order should not
be tested. But the method still should be invoked (giving the same
code coverage), and the method result (exception) should be checked in
a less rigorous way, e.g. it should be a runtime exception.
2009/11/18 Tim Ellison <t....@gmail.com>:
> On 18/Nov/2009 09:19, Alexei Fedotov wrote:
>> Hello Jesse,
>>
>> Your link points to Google code which I cannot probably browse due to
>> ACQ restrictions.
>
> As mentioned elsewhere, it's not an issue.
>
>> Anyway, I guess from your message that Google for
>> the sake of user friendliness added messages to NPE exceptions, thus
>> changing the exception order.
>
> I don't understand that statement?
>
>> I accept usability motivation for
>> proposed wiki change. The motivation still have to be compared with
>> performance motivation when NPE are quickly thrown by means of
>> hardware interrupt without any message.
>>
>> Generally I find usability more important than performance. As for
>> exception messages, I like them only when they add some vital
>> information for a programmer, otherwise they just make information
>> retrieval more challenging. From the other side, there likely exist
>> people who benefit from exception messages if they are localized.
>
> Sure.
>
>> As for dropping tests, I'm stil not convinced. Why not to fix tests
>> instead? We have to be continuously improving.
>
> I think the point is that the order should not be tested as it should
> not be assumed to be consistent across implementations or releases.
>
>> P.S. Concerning your question, I faced a problem with
>> SecurityException testing getCertificates() behavior when worked with
>> [1]. I added many non- specification asserts to the tests to
>> understand when SecurityException should be thrown and be somehow
>> compatible. My JIRA does not reference this problem, though extra
>> asserts can be located in the patch to the unit test. Later we got a
>> related bug report [2] concerning the implementation.
>
> Alexei, am I understanding you right here? Putting assertions into the
> code that are not part of the specification, in order to determine
> behavior, is not the same thing as ensuring exception order priority in
> the case of multiple failure conditions.
>
>> P.P.S. I was looking for a JIRA issue which references a user
>> applciation fail due to exception order and failed. I have found the
>> author of the automatic tool instead [3]. I think it worth listen to
>> him.
>
> I'd be interested to hear from him too, as to the motivation for the
> tool. Was it 'simply' to ensure drop-in replacement compatibility, or
> was there an underlying driver for this?
>
> Regards,
> Tim
>
>> [1] https://issues.apache.org/jira/browse/HARMONY-4569
>> [2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
>> [3] https://issues.apache.org/jira/browse/HARMONY-325
>>
>>
>>
>> On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <je...@google.com> wrote:
>>> For better or for worse, Dalvik was changed long ago to ignore exception
>>> priorities. We get exception messages for NPEs and save branches. The full
>>> set of deltas are here:
>>>
>>> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>>>
>>> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>>>> I don't argue changing exception order for a particular case if the
>>>> change improves code simplicity and gives performance benefit on
>>>> important real load, e.g. the change improved Eclipse startup time by
>>>> 4%.
>>>>
>>> I think the primary difference in our thinking is how much we value
>>> exception priority consistency. I don't believe it has any value and
>>> therefore we're imposing an unnecessary constraint on our code. Does anyone
>>> have a real world example, (perhaps a bugreport) demonstrating where
>>> exception priority incompatibility has caused grief?
>>>
>>
>>
>>
>
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
Tim,
As for my statement about Dalvik's code, it's easier to browse it [1]
(thanks for recalling our ACQ exception about APL) than to understand
my English attempts to rephrase it.
As for my example, the analogy was even more direct. I was trying to
understand when I should throw exception - earlier, or later. And
Jesse is discussing which among two should be thrown first.
[1] http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
2009/11/18 Tim Ellison <t....@gmail.com>:
> On 18/Nov/2009 09:19, Alexei Fedotov wrote:
>> Hello Jesse,
>>
>> Your link points to Google code which I cannot probably browse due to
>> ACQ restrictions.
>
> As mentioned elsewhere, it's not an issue.
>
>> Anyway, I guess from your message that Google for
>> the sake of user friendliness added messages to NPE exceptions, thus
>> changing the exception order.
>
> I don't understand that statement?
>
>> I accept usability motivation for
>> proposed wiki change. The motivation still have to be compared with
>> performance motivation when NPE are quickly thrown by means of
>> hardware interrupt without any message.
>>
>> Generally I find usability more important than performance. As for
>> exception messages, I like them only when they add some vital
>> information for a programmer, otherwise they just make information
>> retrieval more challenging. From the other side, there likely exist
>> people who benefit from exception messages if they are localized.
>
> Sure.
>
>> As for dropping tests, I'm stil not convinced. Why not to fix tests
>> instead? We have to be continuously improving.
>
> I think the point is that the order should not be tested as it should
> not be assumed to be consistent across implementations or releases.
>
>> P.S. Concerning your question, I faced a problem with
>> SecurityException testing getCertificates() behavior when worked with
>> [1]. I added many non- specification asserts to the tests to
>> understand when SecurityException should be thrown and be somehow
>> compatible. My JIRA does not reference this problem, though extra
>> asserts can be located in the patch to the unit test. Later we got a
>> related bug report [2] concerning the implementation.
>
> Alexei, am I understanding you right here? Putting assertions into the
> code that are not part of the specification, in order to determine
> behavior, is not the same thing as ensuring exception order priority in
> the case of multiple failure conditions.
>
>> P.P.S. I was looking for a JIRA issue which references a user
>> applciation fail due to exception order and failed. I have found the
>> author of the automatic tool instead [3]. I think it worth listen to
>> him.
>
> I'd be interested to hear from him too, as to the motivation for the
> tool. Was it 'simply' to ensure drop-in replacement compatibility, or
> was there an underlying driver for this?
>
> Regards,
> Tim
>
>> [1] https://issues.apache.org/jira/browse/HARMONY-4569
>> [2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
>> [3] https://issues.apache.org/jira/browse/HARMONY-325
>>
>>
>>
>> On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <je...@google.com> wrote:
>>> For better or for worse, Dalvik was changed long ago to ignore exception
>>> priorities. We get exception messages for NPEs and save branches. The full
>>> set of deltas are here:
>>>
>>> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>>>
>>> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>>>> I don't argue changing exception order for a particular case if the
>>>> change improves code simplicity and gives performance benefit on
>>>> important real load, e.g. the change improved Eclipse startup time by
>>>> 4%.
>>>>
>>> I think the primary difference in our thinking is how much we value
>>> exception priority consistency. I don't believe it has any value and
>>> therefore we're imposing an unnecessary constraint on our code. Does anyone
>>> have a real world example, (perhaps a bugreport) demonstrating where
>>> exception priority incompatibility has caused grief?
>>>
>>
>>
>>
>
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Tim Ellison <t....@gmail.com>.
On 18/Nov/2009 09:19, Alexei Fedotov wrote:
> Hello Jesse,
>
> Your link points to Google code which I cannot probably browse due to
> ACQ restrictions.
As mentioned elsewhere, it's not an issue.
> Anyway, I guess from your message that Google for
> the sake of user friendliness added messages to NPE exceptions, thus
> changing the exception order.
I don't understand that statement?
> I accept usability motivation for
> proposed wiki change. The motivation still have to be compared with
> performance motivation when NPE are quickly thrown by means of
> hardware interrupt without any message.
>
> Generally I find usability more important than performance. As for
> exception messages, I like them only when they add some vital
> information for a programmer, otherwise they just make information
> retrieval more challenging. From the other side, there likely exist
> people who benefit from exception messages if they are localized.
Sure.
> As for dropping tests, I'm stil not convinced. Why not to fix tests
> instead? We have to be continuously improving.
I think the point is that the order should not be tested as it should
not be assumed to be consistent across implementations or releases.
> P.S. Concerning your question, I faced a problem with
> SecurityException testing getCertificates() behavior when worked with
> [1]. I added many non- specification asserts to the tests to
> understand when SecurityException should be thrown and be somehow
> compatible. My JIRA does not reference this problem, though extra
> asserts can be located in the patch to the unit test. Later we got a
> related bug report [2] concerning the implementation.
Alexei, am I understanding you right here? Putting assertions into the
code that are not part of the specification, in order to determine
behavior, is not the same thing as ensuring exception order priority in
the case of multiple failure conditions.
> P.P.S. I was looking for a JIRA issue which references a user
> applciation fail due to exception order and failed. I have found the
> author of the automatic tool instead [3]. I think it worth listen to
> him.
I'd be interested to hear from him too, as to the motivation for the
tool. Was it 'simply' to ensure drop-in replacement compatibility, or
was there an underlying driver for this?
Regards,
Tim
> [1] https://issues.apache.org/jira/browse/HARMONY-4569
> [2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
> [3] https://issues.apache.org/jira/browse/HARMONY-325
>
>
>
> On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <je...@google.com> wrote:
>> For better or for worse, Dalvik was changed long ago to ignore exception
>> priorities. We get exception messages for NPEs and save branches. The full
>> set of deltas are here:
>>
>> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>>
>> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>>> I don't argue changing exception order for a particular case if the
>>> change improves code simplicity and gives performance benefit on
>>> important real load, e.g. the change improved Eclipse startup time by
>>> 4%.
>>>
>> I think the primary difference in our thinking is how much we value
>> exception priority consistency. I don't believe it has any value and
>> therefore we're imposing an unnecessary constraint on our code. Does anyone
>> have a real world example, (perhaps a bugreport) demonstrating where
>> exception priority incompatibility has caused grief?
>>
>
>
>
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
Hello Jesse,
Your link points to Google code which I cannot probably browse due to
ACQ restrictions. Anyway, I guess from your message that Google for
the sake of user friendliness added messages to NPE exceptions, thus
changing the exception order. I accept usability motivation for
proposed wiki change. The motivation still have to be compared with
performance motivation when NPE are quickly thrown by means of
hardware interrupt without any message.
Generally I find usability more important than performance. As for
exception messages, I like them only when they add some vital
information for a programmer, otherwise they just make information
retrieval more challenging. From the other side, there likely exist
people who benefit from exception messages if they are localized.
As for dropping tests, I'm stil not convinced. Why not to fix tests
instead? We have to be continuously improving.
P.S. Concerning your question, I faced a problem with
SecurityException testing getCertificates() behavior when worked with
[1]. I added many non- specification asserts to the tests to
understand when SecurityException should be thrown and be somehow
compatible. My JIRA does not reference this problem, though extra
asserts can be located in the patch to the unit test. Later we got a
related bug report [2] concerning the implementation.
P.P.S. I was looking for a JIRA issue which references a user
applciation fail due to exception order and failed. I have found the
author of the automatic tool instead [3]. I think it worth listen to
him.
[1] https://issues.apache.org/jira/browse/HARMONY-4569
[2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
[3] https://issues.apache.org/jira/browse/HARMONY-325
On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <je...@google.com> wrote:
> For better or for worse, Dalvik was changed long ago to ignore exception
> priorities. We get exception messages for NPEs and save branches. The full
> set of deltas are here:
>
> http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
>
> 2009/11/17 Alexei Fedotov <al...@gmail.com>
>>
>> I don't argue changing exception order for a particular case if the
>> change improves code simplicity and gives performance benefit on
>> important real load, e.g. the change improved Eclipse startup time by
>> 4%.
>>
>
> I think the primary difference in our thinking is how much we value
> exception priority consistency. I don't believe it has any value and
> therefore we're imposing an unnecessary constraint on our code. Does anyone
> have a real world example, (perhaps a bugreport) demonstrating where
> exception priority incompatibility has caused grief?
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Jesse Wilson <je...@google.com>.
For better or for worse, Dalvik was changed long ago to ignore exception
priorities. We get exception messages for NPEs and save branches. The full
set of deltas are here:
http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
2009/11/17 Alexei Fedotov <al...@gmail.com>
>
> I don't argue changing exception order for a particular case if the
> change improves code simplicity and gives performance benefit on
> important real load, e.g. the change improved Eclipse startup time by
> 4%.
>
I think the primary difference in our thinking is how much we value
exception priority consistency. I don't believe it has any value and
therefore we're imposing an unnecessary constraint on our code. Does anyone
have a real world example, (perhaps a bugreport) demonstrating where
exception priority incompatibility has caused grief?
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
My point is that we should not break existing common rules and drop
test bases not even understanding motivation. Sorry, saving
engineering time to run simple tests and fix the code does not
convince me because it takes human years to create the tests and keep
our implementation compatible.
I don't argue changing exception order for a particular case if the
change improves code simplicity and gives performance benefit on
important real load, e.g. the change improved Eclipse startup time by
4%.
On Tue, Nov 17, 2009 at 1:03 PM, Jesse Wilson <je...@google.com> wrote:
> I should clarify that I'm only thinking about a particular set of unchecked
> exceptions from java.lang: NullPointerException, IllegalArgumentException,
> IllegalStateException, NoSuchElementException and IndexOutOfBoundsException.
>
> Being consistent on checked exceptions like IOException is still beneficial,
> and we should continue to maintain our current behaviour.
>
>
> 2009/11/16 Alexei Fedotov <al...@gmail.com>
>
>> Why do you think that real-world applications do not rely on the
>> exception order?
>
>
> Application code rarely catches the exceptions listed above. These
> exceptions aren't intended to be caught - they usually indicate a programmer
> error. The appropriate fix isn't to catch the exception; instead
> applications fix the code so that no exception is thrown.
>
> Code that does catch exceptions of this sort tends to catch common
> supertypes. I think we all agree that this is common:
> try {
> return someFlakyOperation();
> } catch (RuntimeException e) {
> logger.warning("flaky operation failed", e);
> return someDefaultValue();
> }
>
> For exception priority matching to be beneficial, the following conditions
> must all exist:
>
> - A developer writes code that is broken enough for multiple distinct
> exceptions to qualify. For example, the buffer must be both null and the
> indices out of bounds.
> - The developer runs this broken code on the RI.
> - The developer then decides that instead of fixing the root cause of the
> exception (changing the invalid parameters), that he will instead catch the
> specific exception thrown by the RI.
> - Although the broken call qualifies for multiple exceptions, the first
> problem always hides all others.
>
> There is no value gained by being consistent with a particular build of the
> RI here. The chance that users will notice our efforts are diminishingly
> rare.
>
>
>
>> You are correct that most tests were generated by an automatic tool.
>> Do I understand correctly that we should allow breaking these tests to
>> save time of engineers who work on more important tasks?
>>
>
> Yes. More importantly, I think we should break these tests in order to
> improve performance and simplicity of our code. Breaking these tests is not
> a problem because the tests aren't validating a behaviour that we should
> care about.
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
Sorry, as I've said I failed to find an exact example. Maybe because
all exception incompatibilities were fixed early in the project
beginning, or because they really had a small impact.
On Thu, Nov 19, 2009 at 5:38 PM, Tim Ellison <t....@gmail.com> wrote:
> On 18/Nov/2009 18:15, Jesse Wilson wrote:
>> On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison <t....@gmail.com> wrote:
>>> Being consistent on checked exceptions like IOException is still
>>> beneficial,
>>>
>>> and we should continue to maintain our current behaviour.
>>>
>>> Being consistent ... on throwing priority? So you are suggesting that
>>> we continue to enforce priority order for multiple errors resulting in
>>> exceptions outside the set above?
>>>
>>> Just trying to understand precisely what you are proposing.
>>
>> My focusing on a specific set of exceptions makes more complicated than
>> necessary; sorry about that. Ultimately I agree with the RI's decision that
>> it is bogus to either specify or enforce a particular exception priority.
>
> Shame, I thought you had something there, because I wonder about the
> problems that may ensue if we allow the order of checked/unchecked
> exceptions to change.
>
> For example, consider a stream's "read(buffer) throws IOException"
> method. By definition the application code will have decided on some
> way to handle the IOException.
>
> However, if there are multiple pre-condition errors such as the read()
> being invoked on a closed stream, and the user passing in a null buffer.
> The user code may very well care that the IOException is thrown early,
> and handled, before the NullPointerException is thrown, and possibly
> causing a crash.
>
> Regards,
> Tim
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Tim Ellison <t....@gmail.com>.
On 18/Nov/2009 18:15, Jesse Wilson wrote:
> On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison <t....@gmail.com> wrote:
>> Being consistent on checked exceptions like IOException is still
>> beneficial,
>>
>> and we should continue to maintain our current behaviour.
>>
>> Being consistent ... on throwing priority? So you are suggesting that
>> we continue to enforce priority order for multiple errors resulting in
>> exceptions outside the set above?
>>
>> Just trying to understand precisely what you are proposing.
>
> My focusing on a specific set of exceptions makes more complicated than
> necessary; sorry about that. Ultimately I agree with the RI's decision that
> it is bogus to either specify or enforce a particular exception priority.
Shame, I thought you had something there, because I wonder about the
problems that may ensue if we allow the order of checked/unchecked
exceptions to change.
For example, consider a stream's "read(buffer) throws IOException"
method. By definition the application code will have decided on some
way to handle the IOException.
However, if there are multiple pre-condition errors such as the read()
being invoked on a closed stream, and the user passing in a null buffer.
The user code may very well care that the IOException is thrown early,
and handled, before the NullPointerException is thrown, and possibly
causing a crash.
Regards,
Tim
Re: Doubting exception priority compatibility
Posted by Jesse Wilson <je...@google.com>.
On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison <t....@gmail.com> wrote:
> > Being consistent on checked exceptions like IOException is still
> beneficial,
>
> and we should continue to maintain our current behaviour.
>
> Being consistent ... on throwing priority? So you are suggesting that
> we continue to enforce priority order for multiple errors resulting in
> exceptions outside the set above?
>
> Just trying to understand precisely what you are proposing.
>
My focusing on a specific set of exceptions makes more complicated than
necessary; sorry about that. Ultimately I agree with the RI's decision that
it is bogus to either specify or enforce a particular exception priority.
Re: Doubting exception priority compatibility
Posted by Tim Ellison <t....@gmail.com>.
On 17/Nov/2009 10:03, Jesse Wilson wrote:
> I should clarify that I'm only thinking about a particular set of unchecked
> exceptions from java.lang: NullPointerException, IllegalArgumentException,
> IllegalStateException, NoSuchElementException and IndexOutOfBoundsException.
Why did you pick that set?
> Being consistent on checked exceptions like IOException is still beneficial,
> and we should continue to maintain our current behaviour.
Being consistent ... on throwing priority? So you are suggesting that
we continue to enforce priority order for multiple errors resulting in
exceptions outside the set above?
Just trying to understand precisely what you are proposing.
Regards,
Tim
> 2009/11/16 Alexei Fedotov <al...@gmail.com>
>
>> Why do you think that real-world applications do not rely on the
>> exception order?
>
>
> Application code rarely catches the exceptions listed above. These
> exceptions aren't intended to be caught - they usually indicate a programmer
> error. The appropriate fix isn't to catch the exception; instead
> applications fix the code so that no exception is thrown.
>
> Code that does catch exceptions of this sort tends to catch common
> supertypes. I think we all agree that this is common:
> try {
> return someFlakyOperation();
> } catch (RuntimeException e) {
> logger.warning("flaky operation failed", e);
> return someDefaultValue();
> }
>
> For exception priority matching to be beneficial, the following conditions
> must all exist:
>
> - A developer writes code that is broken enough for multiple distinct
> exceptions to qualify. For example, the buffer must be both null and the
> indices out of bounds.
> - The developer runs this broken code on the RI.
> - The developer then decides that instead of fixing the root cause of the
> exception (changing the invalid parameters), that he will instead catch the
> specific exception thrown by the RI.
> - Although the broken call qualifies for multiple exceptions, the first
> problem always hides all others.
>
> There is no value gained by being consistent with a particular build of the
> RI here. The chance that users will notice our efforts are diminishingly
> rare.
>
>
>
>> You are correct that most tests were generated by an automatic tool.
>> Do I understand correctly that we should allow breaking these tests to
>> save time of engineers who work on more important tasks?
>>
>
> Yes. More importantly, I think we should break these tests in order to
> improve performance and simplicity of our code. Breaking these tests is not
> a problem because the tests aren't validating a behaviour that we should
> care about.
>
Re: Doubting exception priority compatibility
Posted by Jesse Wilson <je...@google.com>.
I should clarify that I'm only thinking about a particular set of unchecked
exceptions from java.lang: NullPointerException, IllegalArgumentException,
IllegalStateException, NoSuchElementException and IndexOutOfBoundsException.
Being consistent on checked exceptions like IOException is still beneficial,
and we should continue to maintain our current behaviour.
2009/11/16 Alexei Fedotov <al...@gmail.com>
> Why do you think that real-world applications do not rely on the
> exception order?
Application code rarely catches the exceptions listed above. These
exceptions aren't intended to be caught - they usually indicate a programmer
error. The appropriate fix isn't to catch the exception; instead
applications fix the code so that no exception is thrown.
Code that does catch exceptions of this sort tends to catch common
supertypes. I think we all agree that this is common:
try {
return someFlakyOperation();
} catch (RuntimeException e) {
logger.warning("flaky operation failed", e);
return someDefaultValue();
}
For exception priority matching to be beneficial, the following conditions
must all exist:
- A developer writes code that is broken enough for multiple distinct
exceptions to qualify. For example, the buffer must be both null and the
indices out of bounds.
- The developer runs this broken code on the RI.
- The developer then decides that instead of fixing the root cause of the
exception (changing the invalid parameters), that he will instead catch the
specific exception thrown by the RI.
- Although the broken call qualifies for multiple exceptions, the first
problem always hides all others.
There is no value gained by being consistent with a particular build of the
RI here. The chance that users will notice our efforts are diminishingly
rare.
> You are correct that most tests were generated by an automatic tool.
> Do I understand correctly that we should allow breaking these tests to
> save time of engineers who work on more important tasks?
>
Yes. More importantly, I think we should break these tests in order to
improve performance and simplicity of our code. Breaking these tests is not
a problem because the tests aren't validating a behaviour that we should
care about.
Re: Doubting exception priority compatibility
Posted by Alexei Fedotov <al...@gmail.com>.
Hi Jesse
Why do you think that real-world applications do not rely on the
exception order? Those people who enabled user applications were asked
to submit their test cases in the simpest form and created some tests.
You are correct that most tests were generated by an automatic tool.
Do I understand correctly that we should allow breaking these tests to
save time of engineers who work on more important tasks?
With best regards, Alexei
BTW, having these tests in our test base allows us being compatible
without illegal reverse engineering.
On Sat, Nov 14, 2009 at 2:19 AM, Jesse Wilson <je...@google.com> wrote:
> Harmony team,
>
> I'm skeptical of the utility of being exception-priority compatible with the
> RI. We have a wiki
> page<http://wiki.apache.org/harmony/Exception-throwing_compatibility>
> describes
> our goals, but I don't think these are worth their costs.
>
> Recently I broke tests by breaking exception priority on this code:
>
> public int read(char[] buffer, int offset, int length) throws
> IOException {
> synchronized (lock) {
> if (isClosed()) {
> throw new IOException(Msg.getString("K005b")); //$NON-NLS-1$
> }
> if (offset < 0 || offset > buffer.length - length || length < 0)
> {
> throw new IndexOutOfBoundsException();
> }
> ...
>
> We have test coverage that asserts the RI's exact exception priority:
>
> 1. if offset is negative, an IndexOutOfBoundsException is thrown
> 2. if buffer is null, a NullPointerException is thrown
> 3. if length is negative, an IndexOutOfBoundsException is thrown
>
> This is very compatible! But it ties our hands from making common sense
> improvements. For example, we cannot cache the buffer length in a local
> variable without disrupting exception priority. The following change
> reorders #1 and #2::
> ...
> *int bufferLength = buffer.length; // cache this in a local
> variable*
> if (offset < 0 || offset > bufferLength - length || length < 0)
> {
> throw new IndexOutOfBoundsException();
> }
>
> Nor can we save branching operations by using bitwise rather than logical
> OR. The following change reorders #2 and #3:
> ...
> if (*offset | length < 0* || offset > buffer.length - length) {
> throw new IndexOutOfBoundsException();
> }
>
> I'm all for compatibility. But I don't believe it is in our best interest to
> strive for this degree of compatibility with the RI. Trying to get this
> level of compatibility takes engineering time away from more useful tasks.
>
> The RI's exception priorities are generally undocumented, and therefore must
> be reverse engineered in each case. It also requires significant effort to
> write test coverage for exception priorities. Although I acknowledge that
> much of this work has already been done, many additional APIs and revisions
> are still ahead of us.
>
> I don't think real-world applications depend on exception priorities. For
> example, I'm highly skeptical that there are programs that only work on
> platforms where the exceptions above are thrown with priority #1, #2, #3. I
> don't think I've ever seen a program that catches IndexOutOfBoundsException.
> In my experience applications catch either the common supertype
> RuntimeException, or they don't catch at all.
>
> Agree/disagree?
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: Doubting exception priority compatibility
Posted by Sean Qiu <se...@gmail.com>.
If I'm the reference implementation, I won't worry about it too. :-)
Best Regards
Sean, Xiao Xia Qiu
2009/11/17 Joshua Bloch <jj...@google.com>
> Folks,
>
> It's worth pointing out that even Sun does not worry about which exception
> to throw when multiple exceptions apply. The exception that is thrown under
> those circumstances can and does change from release to release. Sometimes
> it happens in rather dramatic fashion. For example, when generics were
> adopted, all of a sudden ClassCastException took priority over many other
> exceptions (because the CCE's came from automatically generated bridge
> methods that ran before the hand-written code). So I don't think we should
> worry about this (or test for it).
>
> Josh
>
> On Mon, Nov 16, 2009 at 5:40 AM, Sean Qiu <se...@gmail.com> wrote:
>
> > Yes, in most case, the behavior difference is not critical.
> >
> > But...
> >
> > Sometimes, our user's application may depends on the exception sequence,
> it
> > is rare, but it did happen.
> > (I do encountered this situation before, if you're interested, maybe I
> can
> > find it out.)
> >
> > Then our user's application can't run on Harmony's jre but works well
> with
> > other runtime.
> > From user's perspective, it is really not a happy experience.
> > They might think Harmony's runtime is not strong enough regardless of the
> > benefits as you mentioned.
> > (Although it is just an advanced exception, it may be "trivial" from
> > developer's point of view.)
> >
> > So, IMHO, compatibility is as important as all other code metrics, maybe
> > more important to us.
> > It's worth the extra efforts, because it will bring better user
> experience.
> > At least, it won't stop the application by unexpected exception.
> >
> >
> > Best Regards
> > Sean, Xiao Xia Qiu
> >
> >
> >
> > 2009/11/14 Jesse Wilson <je...@google.com>
> >
> > > Harmony team,
> > >
> > > I'm skeptical of the utility of being exception-priority compatible
> with
> > > the
> > > RI. We have a wiki
> > > page<http://wiki.apache.org/harmony/Exception-throwing_compatibility>
> > > describes
> > > our goals, but I don't think these are worth their costs.
> > >
> > > Recently I broke tests by breaking exception priority on this code:
> > >
> > > public int read(char[] buffer, int offset, int length) throws
> > > IOException {
> > > synchronized (lock) {
> > > if (isClosed()) {
> > > throw new IOException(Msg.getString("K005b"));
> > //$NON-NLS-1$
> > > }
> > > if (offset < 0 || offset > buffer.length - length || length
> <
> > 0)
> > > {
> > > throw new IndexOutOfBoundsException();
> > > }
> > > ...
> > >
> > > We have test coverage that asserts the RI's exact exception priority:
> > >
> > > 1. if offset is negative, an IndexOutOfBoundsException is thrown
> > > 2. if buffer is null, a NullPointerException is thrown
> > > 3. if length is negative, an IndexOutOfBoundsException is thrown
> > >
> > > This is very compatible! But it ties our hands from making common sense
> > > improvements. For example, we cannot cache the buffer length in a local
> > > variable without disrupting exception priority. The following change
> > > reorders #1 and #2::
> > > ...
> > > *int bufferLength = buffer.length; // cache this in a local
> > > variable*
> > > if (offset < 0 || offset > bufferLength - length || length <
> > 0)
> > > {
> > > throw new IndexOutOfBoundsException();
> > > }
> > >
> > > Nor can we save branching operations by using bitwise rather than
> logical
> > > OR. The following change reorders #2 and #3:
> > > ...
> > > if (*offset | length < 0* || offset > buffer.length -
> length)
> > {
> > > throw new IndexOutOfBoundsException();
> > > }
> > >
> > > I'm all for compatibility. But I don't believe it is in our best
> interest
> > > to
> > > strive for this degree of compatibility with the RI. Trying to get this
> > > level of compatibility takes engineering time away from more useful
> > tasks.
> > >
> > > The RI's exception priorities are generally undocumented, and therefore
> > > must
> > > be reverse engineered in each case. It also requires significant effort
> > to
> > > write test coverage for exception priorities. Although I acknowledge
> that
> > > much of this work has already been done, many additional APIs and
> > revisions
> > > are still ahead of us.
> > >
> > > I don't think real-world applications depend on exception priorities.
> For
> > > example, I'm highly skeptical that there are programs that only work on
> > > platforms where the exceptions above are thrown with priority #1, #2,
> > #3.
> > > I
> > > don't think I've ever seen a program that catches
> > > IndexOutOfBoundsException.
> > > In my experience applications catch either the common supertype
> > > RuntimeException, or they don't catch at all.
> > >
> > > Agree/disagree?
> > >
> >
>
Re: Doubting exception priority compatibility
Posted by Joshua Bloch <jj...@google.com>.
Folks,
It's worth pointing out that even Sun does not worry about which exception
to throw when multiple exceptions apply. The exception that is thrown under
those circumstances can and does change from release to release. Sometimes
it happens in rather dramatic fashion. For example, when generics were
adopted, all of a sudden ClassCastException took priority over many other
exceptions (because the CCE's came from automatically generated bridge
methods that ran before the hand-written code). So I don't think we should
worry about this (or test for it).
Josh
On Mon, Nov 16, 2009 at 5:40 AM, Sean Qiu <se...@gmail.com> wrote:
> Yes, in most case, the behavior difference is not critical.
>
> But...
>
> Sometimes, our user's application may depends on the exception sequence, it
> is rare, but it did happen.
> (I do encountered this situation before, if you're interested, maybe I can
> find it out.)
>
> Then our user's application can't run on Harmony's jre but works well with
> other runtime.
> From user's perspective, it is really not a happy experience.
> They might think Harmony's runtime is not strong enough regardless of the
> benefits as you mentioned.
> (Although it is just an advanced exception, it may be "trivial" from
> developer's point of view.)
>
> So, IMHO, compatibility is as important as all other code metrics, maybe
> more important to us.
> It's worth the extra efforts, because it will bring better user experience.
> At least, it won't stop the application by unexpected exception.
>
>
> Best Regards
> Sean, Xiao Xia Qiu
>
>
>
> 2009/11/14 Jesse Wilson <je...@google.com>
>
> > Harmony team,
> >
> > I'm skeptical of the utility of being exception-priority compatible with
> > the
> > RI. We have a wiki
> > page<http://wiki.apache.org/harmony/Exception-throwing_compatibility>
> > describes
> > our goals, but I don't think these are worth their costs.
> >
> > Recently I broke tests by breaking exception priority on this code:
> >
> > public int read(char[] buffer, int offset, int length) throws
> > IOException {
> > synchronized (lock) {
> > if (isClosed()) {
> > throw new IOException(Msg.getString("K005b"));
> //$NON-NLS-1$
> > }
> > if (offset < 0 || offset > buffer.length - length || length <
> 0)
> > {
> > throw new IndexOutOfBoundsException();
> > }
> > ...
> >
> > We have test coverage that asserts the RI's exact exception priority:
> >
> > 1. if offset is negative, an IndexOutOfBoundsException is thrown
> > 2. if buffer is null, a NullPointerException is thrown
> > 3. if length is negative, an IndexOutOfBoundsException is thrown
> >
> > This is very compatible! But it ties our hands from making common sense
> > improvements. For example, we cannot cache the buffer length in a local
> > variable without disrupting exception priority. The following change
> > reorders #1 and #2::
> > ...
> > *int bufferLength = buffer.length; // cache this in a local
> > variable*
> > if (offset < 0 || offset > bufferLength - length || length <
> 0)
> > {
> > throw new IndexOutOfBoundsException();
> > }
> >
> > Nor can we save branching operations by using bitwise rather than logical
> > OR. The following change reorders #2 and #3:
> > ...
> > if (*offset | length < 0* || offset > buffer.length - length)
> {
> > throw new IndexOutOfBoundsException();
> > }
> >
> > I'm all for compatibility. But I don't believe it is in our best interest
> > to
> > strive for this degree of compatibility with the RI. Trying to get this
> > level of compatibility takes engineering time away from more useful
> tasks.
> >
> > The RI's exception priorities are generally undocumented, and therefore
> > must
> > be reverse engineered in each case. It also requires significant effort
> to
> > write test coverage for exception priorities. Although I acknowledge that
> > much of this work has already been done, many additional APIs and
> revisions
> > are still ahead of us.
> >
> > I don't think real-world applications depend on exception priorities. For
> > example, I'm highly skeptical that there are programs that only work on
> > platforms where the exceptions above are thrown with priority #1, #2,
> #3.
> > I
> > don't think I've ever seen a program that catches
> > IndexOutOfBoundsException.
> > In my experience applications catch either the common supertype
> > RuntimeException, or they don't catch at all.
> >
> > Agree/disagree?
> >
>
Re: Doubting exception priority compatibility
Posted by Sean Qiu <se...@gmail.com>.
Yes, in most case, the behavior difference is not critical.
But...
Sometimes, our user's application may depends on the exception sequence, it
is rare, but it did happen.
(I do encountered this situation before, if you're interested, maybe I can
find it out.)
Then our user's application can't run on Harmony's jre but works well with
other runtime.
>From user's perspective, it is really not a happy experience.
They might think Harmony's runtime is not strong enough regardless of the
benefits as you mentioned.
(Although it is just an advanced exception, it may be "trivial" from
developer's point of view.)
So, IMHO, compatibility is as important as all other code metrics, maybe
more important to us.
It's worth the extra efforts, because it will bring better user experience.
At least, it won't stop the application by unexpected exception.
Best Regards
Sean, Xiao Xia Qiu
2009/11/14 Jesse Wilson <je...@google.com>
> Harmony team,
>
> I'm skeptical of the utility of being exception-priority compatible with
> the
> RI. We have a wiki
> page<http://wiki.apache.org/harmony/Exception-throwing_compatibility>
> describes
> our goals, but I don't think these are worth their costs.
>
> Recently I broke tests by breaking exception priority on this code:
>
> public int read(char[] buffer, int offset, int length) throws
> IOException {
> synchronized (lock) {
> if (isClosed()) {
> throw new IOException(Msg.getString("K005b")); //$NON-NLS-1$
> }
> if (offset < 0 || offset > buffer.length - length || length < 0)
> {
> throw new IndexOutOfBoundsException();
> }
> ...
>
> We have test coverage that asserts the RI's exact exception priority:
>
> 1. if offset is negative, an IndexOutOfBoundsException is thrown
> 2. if buffer is null, a NullPointerException is thrown
> 3. if length is negative, an IndexOutOfBoundsException is thrown
>
> This is very compatible! But it ties our hands from making common sense
> improvements. For example, we cannot cache the buffer length in a local
> variable without disrupting exception priority. The following change
> reorders #1 and #2::
> ...
> *int bufferLength = buffer.length; // cache this in a local
> variable*
> if (offset < 0 || offset > bufferLength - length || length < 0)
> {
> throw new IndexOutOfBoundsException();
> }
>
> Nor can we save branching operations by using bitwise rather than logical
> OR. The following change reorders #2 and #3:
> ...
> if (*offset | length < 0* || offset > buffer.length - length) {
> throw new IndexOutOfBoundsException();
> }
>
> I'm all for compatibility. But I don't believe it is in our best interest
> to
> strive for this degree of compatibility with the RI. Trying to get this
> level of compatibility takes engineering time away from more useful tasks.
>
> The RI's exception priorities are generally undocumented, and therefore
> must
> be reverse engineered in each case. It also requires significant effort to
> write test coverage for exception priorities. Although I acknowledge that
> much of this work has already been done, many additional APIs and revisions
> are still ahead of us.
>
> I don't think real-world applications depend on exception priorities. For
> example, I'm highly skeptical that there are programs that only work on
> platforms where the exceptions above are thrown with priority #1, #2, #3.
> I
> don't think I've ever seen a program that catches
> IndexOutOfBoundsException.
> In my experience applications catch either the common supertype
> RuntimeException, or they don't catch at all.
>
> Agree/disagree?
>