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 Wed, 18 Nov 2009 18:23:12 GMT

As for my statement about Dalvik's code, it's easier to browse it [1]
(thanks for recalling our ACQ exception about APL) than to understand
my English attempts to rephrase it.

As for my example, the analogy was even more direct. I was trying to
understand when I should throw exception - earlier, or later. And
Jesse is discussing which among two should be thrown first.

[1] http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git

2009/11/18 Tim Ellison <t.p.ellison@gmail.com>:
> 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?

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

View raw message