I should clarify that I'm only thinking about a particular set of unchecked
exceptions from java.lang: NullPointerException, IllegalArgumentException,
IllegalStateException, NoSuchElementException and IndexOutOfBoundsException.
Being consistent on checked exceptions like IOException is still beneficial,
and we should continue to maintain our current behaviour.
2009/11/16 Alexei Fedotov <alexei.fedo...@gmail.com>
> Why do you think that real-world applications do not rely on the
> exception order?
Application code rarely catches the exceptions listed above. These
exceptions aren't intended to be caught - they usually indicate a programmer
error. The appropriate fix isn't to catch the exception; instead
applications fix the code so that no exception is thrown.
Code that does catch exceptions of this sort tends to catch common
supertypes. I think we all agree that this is common:
try {
return someFlakyOperation();
} catch (RuntimeException e) {
logger.warning("flaky operation failed", e);
return someDefaultValue();
}
For exception priority matching to be beneficial, the following conditions
must all exist:
- A developer writes code that is broken enough for multiple distinct
exceptions to qualify. For example, the buffer must be both null and the
indices out of bounds.
- The developer runs this broken code on the RI.
- The developer then decides that instead of fixing the root cause of the
exception (changing the invalid parameters), that he will instead catch the
specific exception thrown by the RI.
- Although the broken call qualifies for multiple exceptions, the first
problem always hides all others.
There is no value gained by being consistent with a particular build of the
RI here. The chance that users will notice our efforts are diminishingly
rare.
> You are correct that most tests were generated by an automatic tool.
> Do I understand correctly that we should allow breaking these tests to
> save time of engineers who work on more important tasks?
>
Yes. More importantly, I think we should break these tests in order to
improve performance and simplicity of our code. Breaking these tests is not
a problem because the tests aren't validating a behaviour that we should
care about.
