Bug #15872
closedCSV.parse omits close call when block is given – intended or bug?
Description
The current implementation of CSV.parse
doesn't call close
when a block is given:
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:
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?
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- 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.
Updated by kou (Kouhei Sutou) over 5 years ago
- 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 ?
Updated by marcandre (Marc-Andre Lafortune) over 5 years ago
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...