On 18/Nov/2009 18:15, Jesse Wilson wrote:
On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Being consistent on checked exceptions like IOException is still
beneficial,
and we should continue to maintain our current behaviour.
Being consistent ... on throwing
On 18/Nov/2009 18:32, Alexei Fedotov wrote:
One more thing about fixing tests. Ok, the exception order should not
be tested. But the method still should be invoked (giving the same
code coverage), and the method result (exception) should be checked in
a less rigorous way, e.g. it should be a
Sorry, as I've said I failed to find an exact example. Maybe because
all exception incompatibilities were fixed early in the project
beginning, or because they really had a small impact.
On Thu, Nov 19, 2009 at 5:38 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 18/Nov/2009 18:15, Jesse Wilson
Hello Jesse,
Your link points to Google code which I cannot probably browse due to
ACQ restrictions. 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 accept usability motivation for
proposed wiki
2009/11/18 Alexei Fedotov alexei.fedo...@gmail.com:
Hello Jesse,
Your link points to Google code which I cannot probably browse due to
ACQ restrictions.
I haven't browsed the code either, but I don't believe viewing this
code would kick in additional restrictions. If that's true, then Jesse
On Wed, Nov 18, 2009 at 8:47 AM, Nathan Beyer ndbe...@apache.org wrote:
I haven't browsed the code either, but I don't believe viewing this
code would kick in additional restrictions. If that's true, then Jesse
and other Android folks wouldn't be able to contribute much of
anything.
Yeah,
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
On 18/Nov/2009 17:29, Jesse Wilson wrote:
On Wed, Nov 18, 2009 at 8:47 AM, Nathan Beyer ndbe...@apache.org wrote:
I haven't browsed the code either, but I don't believe viewing this
code would kick in additional restrictions. If that's true, then Jesse
and other Android folks wouldn't be
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
On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison t.p.elli...@gmail.com wrote:
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
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 -
One more thing about fixing tests. Ok, the exception order should not
be tested. But the method still should be invoked (giving the same
code coverage), and the method result (exception) should be checked in
a less rigorous way, e.g. it should be a runtime exception.
2009/11/18 Tim Ellison
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
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
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
I would argue that we are doing a better job of ensuring compatibility with
the RI by *not* mandating the same exception priority on these exceptions.
In the RI, they can (and do) change even in minor releases. Our tests are
mandating compatibility with a random snapshot of the RI on an
On Tue, Nov 17, 2009 at 12:13 PM, Joshua Bloch j...@google.com wrote:
I would argue that we are doing a better job of ensuring compatibility with
the RI by *not* mandating the same exception priority on these exceptions.
In the RI, they can (and do) change even in minor releases. Our tests
Hi Jesse
Why do you think that real-world applications do not rely on the
exception order? Those people who enabled user applications were asked
to submit their test cases in the simpest form and created some tests.
You are correct that most tests were generated by an automatic tool.
Do I
Yes, in most case, the behavior difference is not critical.
But...
Sometimes, our user's application may depends on the exception sequence, it
is rare, but it did happen.
(I do encountered this situation before, if you're interested, maybe I can
find it out.)
Then our user's application can't
Folks,
It's worth pointing out that even Sun does not worry about which exception
to throw when multiple exceptions apply. The exception that is thrown under
those circumstances can and does change from release to release. Sometimes
it happens in rather dramatic fashion. For example, when
Harmony team,
I'm skeptical of the utility of being exception-priority compatible with the
RI. We have a wiki
pagehttp://wiki.apache.org/harmony/Exception-throwing_compatibility
describes
our goals, but I don't think these are worth their costs.
Recently I broke tests by breaking exception
21 matches
Mail list logo
