[ruby-core:92817] [Ruby trunk Bug#15872] CSV.parse omits close call when block is given – intended or bug?

[ruby-core:92817] [Ruby trunk Bug#15872] CSV.parse omits close call when block is given – intended or bug?

[mail]

Issue #15872 has been reported by sos4nt (Stefan Schüßler).

----------------------------------------
Bug #15872: CSV.parse omits close call when block is given – intended or bug?
https://bugs.ruby-lang.org/issues/15872

* Author: sos4nt (Stefan Schüßler)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
The current implementation of `CSV.parse` doesn't call `close` when a block is given:
```ruby
def self.parse(*args, &block)
  csv = new(*args)

  return csv.each(&block) if block_given?

  begin
    csv.read
  ensure
    csv.close  # <- never gets here if block is given
  end
end

```

A possible fix would be:

```ruby
def self.parse(*args, &block)
  csv = new(*args)
  if block_given?
    csv.each(&block) 
  else
    csv.read
  end
ensure
  csv.close
end
```

But I'm not sure if this behavior might be intended, given that Ruby's CSV library is quite mature.

Am I missing a use case or is this actually a bug?



-- 
https://bugs.ruby-lang.org/

[ruby-core:92820] [Ruby trunk Bug#15872] CSV.parse omits close call when block is given – intended or bug?

[nobu]

Issue #15872 has been updated by nobu (Nobuyoshi Nakada).

Status changed from Open to Rejected

When a block is given and the argument is an IO-like object, it may not reach its end after exiting the `each` method.




----------------------------------------
Bug #15872: CSV.parse omits close call when block is given – intended or bug?
https://bugs.ruby-lang.org/issues/15872#change-78192

* Author: sos4nt (Stefan Schüßler)
* Status: Rejected
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
The current implementation of `CSV.parse` doesn't call `close` when a block is given:
```ruby
def self.parse(*args, &block)
  csv = new(*args)

  return csv.each(&block) if block_given?

  begin
    csv.read
  ensure
    csv.close  # <- never gets here if block is given
  end
end

```

A possible fix would be:

```ruby
def self.parse(*args, &block)
  csv = new(*args)
  if block_given?
    csv.each(&block) 
  else
    csv.read
  end
ensure
  csv.close
end
```

But I'm not sure if this behavior might be intended, given that Ruby's CSV library is quite mature.

Am I missing a use case or is this actually a bug?



-- 
https://bugs.ruby-lang.org/

[ruby-core:92831] [Ruby trunk Bug#15872] CSV.parse omits close call when block is given – intended or bug?

[kou]

Issue #15872 has been updated by kou (Kouhei Sutou).

Assignee set to kou (Kouhei Sutou)

`CSV.parse` expects a `String` as the input. So `close` isn't necessary.

If you have a problem case, could you report this with the problem case to https://github.com/ruby/csv/issues ?

----------------------------------------
Bug #15872: CSV.parse omits close call when block is given – intended or bug?
https://bugs.ruby-lang.org/issues/15872#change-78210

* Author: sos4nt (Stefan Schüßler)
* Status: Rejected
* Priority: Normal
* Assignee: kou (Kouhei Sutou)
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
The current implementation of `CSV.parse` doesn't call `close` when a block is given:
```ruby
def self.parse(*args, &block)
  csv = new(*args)

  return csv.each(&block) if block_given?

  begin
    csv.read
  ensure
    csv.close  # <- never gets here if block is given
  end
end

```

A possible fix would be:

```ruby
def self.parse(*args, &block)
  csv = new(*args)
  if block_given?
    csv.each(&block) 
  else
    csv.read
  end
ensure
  csv.close
end
```

But I'm not sure if this behavior might be intended, given that Ruby's CSV library is quite mature.

Am I missing a use case or is this actually a bug?



-- 
https://bugs.ruby-lang.org/

[ruby-core:92841] [Ruby trunk Bug#15872] CSV.parse omits close call when block is given – intended or bug?

[ruby-core]

Issue #15872 has been updated by marcandre (Marc-Andre Lafortune).


FWIW, I believe this is a bug.

> When a block is given and the argument is an IO-like object, it may not reach its end after exiting the each method 

You mean if the block interrupts the processing with `break`, `return` or `raise`? Maybe it should close it in those cases (I think it still should), but for the normal case it should definitely `close` the IO when exiting normally.

> CSV.parse expects a String as the input

This is incorrect. CSV methods expect a String or an IO.

> If you have a problem case, could you report this with the problem case to https://github.com/ruby/csv/issues ?

Is there information anywhere about where to file issues? I find it quite inconvenient for users to have to move issues here and there... An issue filed on github recently had a comment to file it here, now here is the contrary...

----------------------------------------
Bug #15872: CSV.parse omits close call when block is given – intended or bug?
https://bugs.ruby-lang.org/issues/15872#change-78223

* Author: sos4nt (Stefan Schüßler)
* Status: Rejected
* Priority: Normal
* Assignee: kou (Kouhei Sutou)
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
The current implementation of `CSV.parse` doesn't call `close` when a block is given:
```ruby
def self.parse(*args, &block)
  csv = new(*args)

  return csv.each(&block) if block_given?

  begin
    csv.read
  ensure
    csv.close  # <- never gets here if block is given
  end
end

```

A possible fix would be:

```ruby
def self.parse(*args, &block)
  csv = new(*args)
  if block_given?
    csv.each(&block) 
  else
    csv.read
  end
ensure
  csv.close
end
```

But I'm not sure if this behavior might be intended, given that Ruby's CSV library is quite mature.

Am I missing a use case or is this actually a bug?



-- 
https://bugs.ruby-lang.org/