harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Bloch <...@google.com>
Subject Re: Doubting exception priority compatibility
Date Mon, 16 Nov 2009 17:57:50 GMT
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