cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9985) Introduce our own AbstractIterator
Date Thu, 06 Aug 2015 17:59:05 GMT


Ariel Weisberg commented on CASSANDRA-9985:

#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?

Iterator foo = bar.iterator();

while (foo.hasNext())
try {
catch (Exception e)
//Log or whatever

If we do #2 is #1 still a lot of code?

> Introduce our own AbstractIterator
> ----------------------------------
>                 Key: CASSANDRA-9985
>                 URL:
>             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

View raw message