harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: Doubting exception priority compatibility
Date Mon, 16 Nov 2009 12:22:18 GMT
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 <jessewilson@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/

Mime
View raw message