harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Doubting exception priority compatibility
Date Wed, 18 Nov 2009 18:01:43 GMT
On 18/Nov/2009 09:19, Alexei Fedotov wrote:
> Hello Jesse,
> 
> Your link points to Google code which I cannot probably browse due to
> ACQ restrictions.

As mentioned elsewhere, it's not an issue.

> Anyway, I guess from your message that Google for
> the sake of user friendliness added messages to NPE exceptions, thus
> changing the exception order.

I don't understand that statement?

> I accept usability motivation for
> proposed wiki change. The motivation still have to be compared with
> performance motivation when NPE are quickly thrown by means of
> hardware interrupt without any message.
> 
> Generally I find usability more important than performance. As for
> exception messages, I like them only when they add some vital
> information for a programmer, otherwise they just make information
> retrieval more challenging. From the other side, there likely exist
> people who benefit from exception messages if they are localized.

Sure.

> As for dropping tests, I'm stil not convinced. Why not to fix tests
> instead? We have to be continuously improving.

I think the point is that the order should not be tested as it should
not be assumed to be consistent across implementations or releases.

> P.S. Concerning your question, I faced a problem with
> SecurityException testing getCertificates() behavior when worked with
> [1]. I added many non- specification asserts to the tests to
> understand when SecurityException should be thrown and be somehow
> compatible. My JIRA does not reference this problem, though extra
> asserts can be located in the patch to the unit test. Later we got a
> related bug report [2] concerning the implementation.

Alexei, am I understanding you right here?  Putting assertions into the
code that are not part of the specification, in order to determine
behavior, is not the same thing as ensuring exception order priority in
the case of multiple failure conditions.

> P.P.S. I was looking for a JIRA issue which references a user
> applciation fail due to exception order and failed. I have found the
> author of the automatic tool instead [3]. I think it worth listen to
> him.

I'd be interested to hear from him too, as to the motivation for the
tool.  Was it 'simply' to ensure drop-in replacement compatibility, or
was there an underlying driver for this?

Regards,
Tim

> [1] https://issues.apache.org/jira/browse/HARMONY-4569
> [2] http://markmail.org/thread/ckfp3wy6dhrzjwh7
> [3] https://issues.apache.org/jira/browse/HARMONY-325
> 
> 
> 
> On Tue, Nov 17, 2009 at 8:20 PM, Jesse Wilson <jessewilson@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.fedotov@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?
>>
> 
> 
> 


Mime
View raw message