On 17/Nov/2009 10:03, Jesse Wilson 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.
Why did you pick that set?
> Being consistent on checked exceptions like IOException is still beneficial,
> and we should continue to maintain our current behaviour.
Being consistent ... on throwing priority? So you are suggesting that
we continue to enforce priority order for multiple errors resulting in
exceptions outside the set above?
Just trying to understand precisely what you are proposing.
Regards,
Tim
> 2009/11/16 Alexei Fedotov
>
>> 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.
>