Tim, 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.elli...@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 <jessewil...@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.fedo...@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 / Алексей Федотов, http://www.telecom-express.ru/ http://harmony.apache.org/ http://www.expressaas.com/ http://openmeetings.googlecode.com/
