From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id E2AE71F934 for ; Mon, 21 Dec 2020 13:46:12 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7B2F7120CD2; Mon, 21 Dec 2020 22:45:25 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id A5A87120CD0 for ; Mon, 21 Dec 2020 22:45:23 +0900 (JST) Received: by filterdrecv-p3las1-685fdc5bbc-dhm6v with SMTP id filterdrecv-p3las1-685fdc5bbc-dhm6v-19-5FE0A71F-14 2020-12-21 13:46:07.19453849 +0000 UTC m=+917028.488791780 Received: from herokuapp.com (unknown) by ismtpd0028p1iad2.sendgrid.net (SG) with ESMTP id zqPvGMb7SA-mUxPQt9j-1w for ; Mon, 21 Dec 2020 13:46:07.066 +0000 (UTC) Date: Mon, 21 Dec 2020 13:46:07 +0000 (UTC) From: intrip@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 77458 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 16816 X-Redmine-Issue-Author: headius X-Redmine-Sender: jbeschi X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?oaR2Qha5nZX19btOTAeXA7Iitrle6ciO5zOKgmP83LCVBXTWGvN9z=2Fi4JsShsr?= =?us-ascii?Q?N7zR0ZrDO1rMizFN6S5AhUSam3FhADVnR7apZMt?= =?us-ascii?Q?sQ6CHjDUCtOMxlBYglT9mh5nmZiuOUcDIAM7hs9?= =?us-ascii?Q?3LeCfOBIlBMyNsgZDxRS=2FsBzw+amjkIaQfFdxWr?= =?us-ascii?Q?OpmVJHioXha2SBtxcqYN4npNl4AnjNkUt2ihnfw?= =?us-ascii?Q?5S1knHS=2FaTjUronek=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 101587 Subject: [ruby-core:101587] [Ruby master Bug#16816] Prematurely terminated Enumerator should stay terminated X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16816 has been updated by jbeschi (jacopo beschi). I'd like to try working on this fix: is it possible? ---------------------------------------- Bug #16816: Prematurely terminated Enumerator should stay terminated https://bugs.ruby-lang.org/issues/16816#change-89373 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal * ruby -v: all * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- When iterating over an Enumerator, there are three different possible results of calling `next`: 1. The next item is returned and a cursor is advanced 2. There's no next item and the Enumerator will forever raise `StopIteration` 3. There's an error getting the next item which is raised out of `next` This third case has some unexpected behavior that I discovered while working on https://github.com/jruby/jruby/issues/6157 It seems that when an Enumerator fails prematurely with an exception, any subsequent call to #next will cause it to restart. This can be seen in a simple script I used to write a ruby/spec in https://github.com/jruby/jruby/pull/6190 ```ruby Enumerator.new { 2.times {|i| raise i.to_s } }.tap {|f| p 2.times.map { f.next rescue $!.message } } ``` The output from this is `[0, 0]`. After the iteration fails, the second `next` call causes it to restart and it fails again. Contrast this to the behavior of item 3 above; when an Enumerator finishes iterating without error, it remains "finished" forever and can't be restarted. I believe the restarting behavior is at best undocumented behavior and at worst incorrect and unspected. Take this example: ```ruby e = Enumerator.new { |y| c = new_database_cursor 5.times { y.yield c.next_result } } ``` If `next_result` here raises an error, a subsequent call to `next` on this enumerator will cause it to restart, re-acquire the cursor, and begin again. As another example I ask a question: how do you indicate that an Enumerator failed due to an error, and *keep it failed* so it doesn't restart again? -- https://bugs.ruby-lang.org/