harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: Doubting exception priority compatibility
Date Tue, 17 Nov 2009 14:34:02 GMT
My point is that we should not break existing common rules and drop
test bases not even understanding motivation. Sorry, saving
engineering time to run simple tests and fix the code does not
convince me because it takes human years to create the tests and keep
our implementation compatible.

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

On Tue, Nov 17, 2009 at 1:03 PM, Jesse Wilson <jessewilson@google.com> wrote:
> 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.

With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,

View raw message