Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of jessewilson@google.com
 designates 216.239.33.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record;
	b=gvO+tDUvfEEYN2VrKzXAKuQi3ziTeFZ3melaquHM2fm1w6g1smCh+hJFQqOatt52j
	W4a9pRd1+JaAcz2484x5A==
MIME-Version: 1.0
From: Jesse Wilson <jessewilson@google.com>
Date: Fri, 13 Nov 2009 15:19:48 -0800
Message-ID: <a43fbc6a0911131519s60124d3ayaf5b302dc3d4598f@mail.gmail.com>
Subject: Doubting exception priority compatibility
To: Harmony Dev <dev@harmony.apache.org>
Content-Type: multipart/alternative; boundary=00151773eaa090fe4d047848e653

--00151773eaa090fe4d047848e653
Content-Type: text/plain; charset=UTF-8

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?

--00151773eaa090fe4d047848e653--