If I'm the reference implementation, I won't worry about it too. :-) Best Regards Sean, Xiao Xia Qiu
2009/11/17 Joshua Bloch <j...@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....@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 <jessewil...@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? > > > > > >
