<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think I’d either just end the sequence on an error, or do like you were thinking and have a function/computed property that gives an array containing all the rows which had an error or something.<div class=""><br class=""></div><div class="">I’m not a DB guy, though.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 12, 2016, at 1:53 PM, Jens Alfke via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">What should one do, when implementing a Generator, if the underlying data source can experience errors? Generator.next isn’t allowed to throw, only to return nil at the end of the sequence.<div class=""><br class=""></div><div class="">The only idea I can think of is to add an `error` property to my Generator implementation, and request that the caller check it after the iteration ends, and/or a `checkForError()` method that can throw an error if there is one:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var q: Query = db.query(…)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for (row in q) { … }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>q.checkForError()</div><div class=""><br class=""></div><div class="">As the example implies, this problem comes up when creating Swift bindings for database iterators/cursors. Generator is the obvious protocol to implement, especially since without it you don’t get the idiomatic for/in loop, but the `next` method <i class="">does</i> have to hit the database, so it has the possibility of I/O errors.</div><div class=""><br class=""></div><div class="">Another possibility is to do all the failable database work up front in the `query` method that creates the Generator, but this means all the results have to be cached in memory, which isn’t scaleable. (Keep in mind I work for a <a href="http://couchbase.com/" class="">database company</a> whose customers often have multi-terabyte data sets.)</div><div class=""><br class=""></div><div class="">I know there’s been a proposal (by Brent Royal-Gordon) to allow property accessors and subscripts to throw, which I strongly endorse, but I think we also need to allow Generators to throw. Fodder for the swift-evolution list…</div><div class=""><br class=""></div><div class="">—Jens</div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></div></div></body></html>