harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: Doubting exception priority compatibility
Date Tue, 17 Nov 2009 10:03:52 GMT
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.fedotov@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.

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