harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Qiu <sean.xx....@gmail.com>
Subject Re: Doubting exception priority compatibility
Date Tue, 17 Nov 2009 08:03:19 GMT
If I'm the reference implementation, I won't worry about it too.  :-)

Best Regards
Sean, Xiao Xia Qiu



2009/11/17 Joshua Bloch <jjb@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 <sean.xx.qiu@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 <jessewilson@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?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message