I would argue that we are doing a better job of ensuring compatibility with the RI by *not* mandating the same exception priority on these exceptions. In the RI, they can (and do) change even in minor releases. Our tests are mandating compatibility with a random snapshot of the RI on an implementation detail that the RI maintainers consider unimportant. We are thus encouraging our users to depend on this implementation detail. That just doesn't make sense.
Interestingly, Sun went so far as to *prohibit *specifying which exception is to be thrown if multiple exceptions apply, 8 years ago: http://bugs.sun.com/view_bug.do?bug_id=4462062 . They actually filed a bug to change some documentation that specified this implementation detail Josh P.S. I would add several exceptions to Jesse's list including ClassCastException (common for sorted collections, and highly implementation dependent). On Tue, Nov 17, 2009 at 9:20 AM, Jesse Wilson <jessewil...@google.com>wrote: > For better or for worse, Dalvik was changed long ago to ignore exception > priorities. We get exception messages for NPEs and save branches. The full > set of deltas are here: > > > http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git > > 2009/11/17 Alexei Fedotov <alexei.fedo...@gmail.com> > > > > I don't argue changing exception order for a particular case if the > > change improves code simplicity and gives performance benefit on > > important real load, e.g. the change improved Eclipse startup time by > > 4%. > > > > I think the primary difference in our thinking is how much we value > exception priority consistency. I don't believe it has any value and > therefore we're imposing an unnecessary constraint on our code. Does anyone > have a real world example, (perhaps a bugreport) demonstrating where > exception priority incompatibility has caused grief? >
