[
https://issues.apache.org/jira/browse/CASSANDRA-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14660488#comment-14660488
]
Ariel Weisberg edited comment on CASSANDRA-9985 at 8/6/15 6:32 PM:
-------------------------------------------------------------------
#1 seems less important. #2 seems important. My thinking is that this is
library code we'll never touch again so ugly isn't a great reason. Performance
would be, but that would be trading performance for problems down the road. If
performance were the reason then maybe tying it to assertions?
WRT to #2. In practice computeNext is definitely going to throw. Now what are
the odds the exception handling keeps the iterator in scope, and then comes
back to try and use it? Not so bad maybe?
{code}
Iterator foo = bar.iterator();
while (foo.hasNext())
{
try
{
//stuff
}
catch (Exception e)
{
//Log or whatever
}
}
{code}
If we do #2 is #1 still a lot of code?
Edit to add. Thinking about #2, I guess this is an infinite loop anyways so
it's game over.
Final edit... ok. So with the current code hasNext() will throw and that isn't
caught. So it's really unlikely someone will have a loop that hits the iterator
twice after it throws. The only way it will happen is if they call next()
without calling hasNext() which they would if they were iterating two things
that are the same size.
was (Author: aweisberg):
#1 seems less important. #2 seems important. My thinking is that this is
library code we'll never touch again so ugly isn't a great reason. Performance
would be, but that would be trading performance for problems down the road. If
performance were the reason then maybe tying it to assertions?
WRT to #2. In practice computeNext is definitely going to throw. Now what are
the odds the exception handling keeps the iterator in scope, and then comes
back to try and use it? Not so bad maybe?
{code}
Iterator foo = bar.iterator();
while (foo.hasNext())
{
try
{
//stuff
}
catch (Exception e)
{
//Log or whatever
}
}
{code}
If we do #2 is #1 still a lot of code?
Edit to add. Thinking about #2, I guess this is an infinite loop anyways so
it's game over.
> Introduce our own AbstractIterator
> ----------------------------------
>
> Key: CASSANDRA-9985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9985
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Trivial
> Fix For: 3.0.0 rc1
>
>
> The Guava AbstractIterator not only has unnecessary method call depth, it is
> difficult to debug without attaching source. Since it's absolutely trivial to
> write our own, and it's used widely within the codebase, I think we should do
> so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
