From: "xibbar (Takeyuki FUJIOKA)" <xibbar@...>
Date: 2013-04-19T14:27:37+09:00
Subject: [ruby-core:54454] [ruby-trunk - Bug #7940][Assigned] Mistaken use of inline rescues in stdlib


Issue #7940 has been updated by xibbar (Takeyuki FUJIOKA).

Status changed from Closed to Assigned
Assignee changed from xibbar (Takeyuki FUJIOKA) to dblack (David Black)

update only my part.
please consider your part > dblack.
----------------------------------------
Bug #7940: Mistaken use of inline rescues in stdlib
https://bugs.ruby-lang.org/issues/7940#change-38735

Author: Mon_Ouie (Mon ou��e)
Status: Assigned
Priority: Normal
Assignee: dblack (David Black)
Category: lib
Target version: current: 2.1.0
ruby -v: ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]
Backport: 


Hey,

There are two uses of inline rescues in stdlib that look dubious. They are unlikely to ever cause any harm, but still. They've been there for a while now, and are still in trunk. I attached a patch that changes both of them.

In cgi/session.rb:

      def delete
        File::unlink @path+".lock" rescue nil
        File::unlink @path+".new" rescue nil
        File::unlink @path rescue Errno::ENOENT
      end

The ``rescue`` part should be on the next line (this has been introduced in a commit that changed indentation).

In scanf.rb:660:

   seek(start_position + matched_so_far, IO::SEEK_SET) rescue Errno::ESPIPE

was more likely meant to just silence Errno::ESPIPE exceptions.


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