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-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham 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 29B621F8C1 for ; Thu, 7 May 2020 08:17:56 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 31A35120A8E; Thu, 7 May 2020 17:17:32 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5CBDB120A8D for ; Thu, 7 May 2020 17:17:30 +0900 (JST) Received: by filterdrecv-p1iad2-asgard1-688d55b576-r8x7t with SMTP id filterdrecv-p1iad2-asgard1-688d55b576-r8x7t-16-5EB3C42D-53 2020-05-07 08:17:49.896014825 +0000 UTC m=+225287.901508875 Received: from herokuapp.com (unknown) by ismtpd0007p1iad2.sendgrid.net (SG) with ESMTP id a7ARoPbOQeKQlwUXvAHJ7g for ; Thu, 07 May 2020 08:17:49.941 +0000 (UTC) Date: Thu, 07 May 2020 08:17:50 +0000 (UTC) From: ko1@atdot.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 73937 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 16816 X-Redmine-Issue-Author: headius X-Redmine-Sender: ko1 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?fVTMYOBjtdvXNcWwrscBhLsHItUXVK5L4mtnq0mdcRcepP5b539mxGW6wix4sv?= =?us-ascii?Q?EqzlznzQF+pHgeOGpDKEJ6SJfizdmZPNXv5Y+gV?= =?us-ascii?Q?P=2FdoEggMzUXaK3PpH6LsgLpgE21YkxBBO1AAuh5?= =?us-ascii?Q?1QMsusADi=2F06OVnfwNK+fUSWyTL3ofAYmcuVftQ?= =?us-ascii?Q?1jXdYEhSYP=2FYWJA+29zGmNzPVFPziOZjy1F=2FLbX?= =?us-ascii?Q?Nw+qpdt++tiAKgndw=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 98176 Subject: [ruby-core:98176] [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 ko1 (Koichi Sasada). Do you propose that the following your example: ``` Enumerator.new { 2.times {|i| raise i.to_s } }.tap {|f| p 2.times.map { f.next rescue $!.message } } ``` should outputs `["0", "iteration reached an end"]` ? ---------------------------------------- Bug #16816: Prematurely terminated Enumerator should stay terminated https://bugs.ruby-lang.org/issues/16816#change-85416 * 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/