#9 楼 @Canmel 可以直接

def xxx
rescue #可选
ensure #可选 不管是否发生异常是否捕获异常都会执行 (finally)
end

不过你写的相当于的那个形式少了一个 end, 因为给了 begin，rescue 就跟着 begin 了，begin 和 def 各自有一个 end

说到单独用 ensure 有个套路 (可能用不到但会读到)

def foo  #不希望出现在异常回溯(backtrace)中的方法，如就是简单封装另一个方法bar
   bar
ensure
   $@.shift if $@ # $@是异常回溯的数组或nil(无异常发生)，移除掉第一项(含有foo的这一项)
end

#14 楼 @jasl 其实这样的回答我是认可的，而且我基本上是暗自钦点 rc 源了（见#11 我的解释）。但是作为脚本，并且我的标题是换源工具 (中立向) 而不是换 RC 源的工具 (特化向)， 毕竟我和楼上的 dalao 不一样，并没有 ruby-china 的钦点的立场。

作为换 RC 源的情况可以做另一个工具或者加选项，那又是另一件事了，起码我不能用一个中立的 repo，明显做钦点的事情吧。其他的回答里面提到的 information security(vulnerability) 的问题，跟这个工具在意的 information safety(availability) 的问题还是有点不同的。

@ #10 楼 @jasl

Ruby China 镜像是国内最首选考虑的镜像（你承认的），那直接介绍和使用 Ruby China 镜像就已经解决问题了，遇到访问不畅的情况，及时提交 issue。

前一句我承认，后一句我只能说我一般不提交也不建议优先 issue，一般提交 pr，这样对于当时发生问题的个例解决问题的时间进度比较有利。

#10 楼 @jasl 说两个事， 第一，

既然假设用户不知道 Ruby China 镜像，那更不会知道你的脚本，用户真不知道 Ruby China 镜像，直接告诉他 Ruby China 镜像就好了

用户不知道 RC 镜像但有可能知道我的脚本，事实上我是 QQ 群党，之前论坛上来得不多，也同样很多不来论坛的人士。这是论坛的普及问题，如果普及力度不够再怎么样也只会有种钦点的感觉。

第二，

安全是最重要的问题，任何时候都必须选择受信任的源或者镜像

用户真不知道 RC，也以跑起来为第一要务的情况，是不能光说安全的。 给你讲个真实的故事，有个人在 rails 群找源，当时还是 ruby.taobao.org 的时代，然后其他人随口说了句淘宝源。然后他去淘宝上面逛了一下午没看到卖源的，接着他就从http://rubygems.org 手动下载* .gem 然后本地安装，然后这些 gem 又有依赖 gem 吧，然后人就继续手动解决依赖关系，反正最后也就陆续装上了几个 gem，也没有解决他的主要问题。

虽然当时现场是当笑话看的，这也可能是个个例，我想说的只是，光说淘宝源或者 ruby-china 源，知道的还是知道，不知道的还是不知道。安全问题当然重要，但人家要求的是 availability 的时候强调 security 是毫无意义的。

第三

对于环境问题，Ruby 在 Windows 环境的生态就是不好：
Ruby 官方不提供 Windows 的构建版本，官方推荐的 Ruby Installer 不能及时跟进 Ruby 最新版本

https://github.com/ruby/ruby/blob/trunk/win32/configure.bat
请解释用这个成功跟进到 HEAD，而且其依赖工具链可以只用 winsdk.exe 安装的理由。
可以理解你把[*-mingw32]当做 win 上全部 ruby 构建的理由，毕竟[*-mswin32]的 case 是另一个折腾方向。

且 gem instaill rails 现在可以直接在 windows 装。

第四 我所谓的非主流只是自嘲而并不是什么把柄，你所谓的主流不要给人一种钦点的感觉，世界上都在打破和融合原来的界限，比如 rubyinstaller 从无到有， rails 现在无障碍在 windows 下gem install，而我们还在拒绝给 windows 用户技术支持，是想等彻底成熟了直接拿来别人的成果吗。

#9 楼 @kgen

大家关心的安全问题

• 自动找个源居然不是 ruby-china.org 第一这才是最危险的。

为何不直接写呢

• 有两个 option 这是公认了的，即便只有一个 option 直接写会给人一种钦点的感觉不够灵活，写程序总要在解决现在问题基础上泛化一下解决几个未来可能的问题。
• 未来可能的问题是什么呢？
  • ruby-china 的 url 被挤下去了
  • 临时局部地区的不可访问

我这个脚本并不是一定要钦点本论坛的源或者黑它的立场。你知道我为了跟进这个结果换了多少个百度关键词吗
如果想要完全钦点的你可以rails new app -m https://raw.githubusercontent.com/RGSS3/rails-new/master/zh-CN/win/app.rb

#6 楼 @hging 见我的解释的第一节

#5 楼 @huacnlee 我长期在 windows 下维护，mirror list 也是另一种方式（见 repo），但我也希望发现更多的源，而且曾经连不上 ruby-china 用了备选 sdutlinux 一段时间，速度还是可以的。

• 我说这么多就在于表明，即便只有两条路（甚至可能只有一条），也还是可以做一个泛化的工具，因为 pragmatic way。而且是 Ruby 解决 Ruby 的问题，不是某 shell 解决 ruby 的环境问题。

• 为何不能换环境的问题，可能我对环境的依存不是那么大吧，而且 ruby 系列对 windows 的支持是越来越好了，至少我现在接触到的问题里面，只有 rubinius 是官方明确表明不支持 windows，而且我也尝试了一周还是移植失败了的。至于其他的问题…… 不过我的路线可能比较非主流，11 年开始玩 RPGMaker，RPGMaker 的 Ruby 不能 require 二进制插件的问题（比如 socket.so），以及无法使用 Fiddle 作为 windows 回调函数的问题，到现在也找到了 Ruby way 的解决方法。而且我现在主要的方向是 Ruby 生成，Ruby 的 runtime 和生成代码的 runtime 可以不在一个环境，所以对环境的依赖真心不大。

如果要提取数据量大的话，直接全部读入然后扫描换行符位置然后提取可能更快，毕竟相当于全部缓存或者按行缓存和拼接。时间空间平衡度是不一样的。

ruby 里面异常处理的普通来说是 raise / rescue
要进行继续处理而言用 yield/Fiber.yield 甚至 callcc
而 catch/throw 的作用并不像在其它语言里面一样是异常处理，更多的是流程控制。
比如快速跳出多重方法/catch 块，throw 的作用是跳到同名 catch 块的后续，catch 块可以有返回值，一般是最后一条表达式的值，发生 throw 时，如果 throw 带了第二个参数那么以这个参数作为值
比如

a = catch :foo do
  catch :bar do
     throw :foo, 3
  end
end

则 throw 直接让 catch :foo 返回且之后 a = 3

#3 楼 @marksloan 楼主我读书不多，当然认可层主这一楼的方法。层主的担忧不无道理，但是也并不见得有这么大的风险。毕竟层主的描述是有具体上下文的，而我这个脚本的写作也是有具体上下文的，并且两者并不太一样。

不过既然层主是谈解决方案，这里谈一下这个脚本作为微型产品的合理性的角度，并非一定要争论什么的，而且真的出现了此类攻击，甚至可以作为 rails 或相关 gems 的安全性的一个技术研究蜜罐，见详述 ：

• 用户群的角度 (谁会用这个脚本)：

  • 已有 gems.ruby-china.org 或者其他长期固定源的用户自然不需要用。
  • 经常不在一个地方或移动式开发，或
  • 演示给新手或需要快速展开的环境，出来什么网站是可见的，并且不需要临时购买或者注册翻墙工具的情况，（甚至层主还给了推荐码）。
    • 对于其他人，当然可以直接换成 gem sources -r https://rubygems.org/ -a http[s]://gems.ruby-china.org/
    • 对于新手，应当说两句话，https://rubygems.org/ 是最权威的源，http[s]://gems.ruby-china.org/ 是在天朝最应当首选考虑的镜像，这么说不致于造成误导和混淆。

• 开源自动化的角度

  • you can fork it as your own tool
  • 这脚本是从人搜索 Ruby 源的方式和角度出发的。(即用户未知 gems.ruby-china.org )
    • 如果木马站针对这个我今天至少就维护了三次代码逻辑 (对应也换了三个 codepad.org 路径) 的地址进行欺骗
    • 甚至不出一个月排名就挤下去了 ruby-china.org
    • 手动百度源的用户一样中招 hhh
    • 强行替换和只从百度取属于体验问题而并非绑架问题，-ropen-uri -e 本来就是 geek 角度，从 geek 角度到 UX 角度本来就有一个过程。

• RubyGems 源的角度（源的问题，不能算是完全解决）

  • windows 无默认证书 (一般可对应改用 http，脚本已涉及，https://gems.ruby-china.org/ 已提到)
  • 急于在线调试 push 到 rubygems.org 的 gem。(当然 https://gems.ruby-china.org/ 也可手动进行一次立即同步，用到了吗？)

• 被木马站针对的问题的对应以及攻击的角度

  • 常用的 curl -sSL https://get.rvm.io | bash
    • 如有欺骗攻击，与我这里是同类的，虽然是个 ssl，能到层主说的威胁程度，那也扛不住证书欺骗和 DNS 污染。
    • rvm.io 也要求用户首先用 gpg 校验，而存在一些人和教程也没进行校验步骤。
    • 如果出现了层主所说的攻击，如果只给一个月时间，似乎更应该走 rvm 的路线更加广泛。
    • 至少也是 http://gems.ruby-china.org/ 的 DNS 污染更加方便
  • 木马具体逻辑放置的位置及工程的角度:
    • 一般不会是 gem 中
    • 因为部署时就该用正式的方法去 bundle install 一套，gem 中如有奇怪的逻辑也带不到对面（但生成的除外，下述）
    • 可能是生成器等生成的代码中
      • 开发者可能会直接修改的，如 controller 和一些启动配置等。如果是层主那种高要求的担忧，是逃不过 Code Review 的
        • 当然也有安全级别高但是不进行 Code Review 的情况，这个问题出在人员。
      • 开发者不直接改的，可以追溯到 bundle install 中，同前一节。
    • 层主和我都能想到奇怪的攻击方法，还能绕开这个部分的 1,2 节，但没有进行攻击，从经常使用 Ruby 进行开发和维护的开发者数量来看，孤陋寡闻的我暂且认为绕开并且攻击而且大面积扩散是大牛闲闹着玩……
      • 真的出现了此类攻击
      • 并且绕开了新手用户群和工程代码质量管理
      • 那其实有把用这个脚本的工程作为蜜罐探讨 rails 或有关的 gems 中植入木马的技术问题的必要性了，也不只是这一个脚本的个例了。

#1 楼 @Rei 那那个人一定很会 SEO，毕竟我的动态源表其实是：

u = get("http://www.baidu.com/s?wd=ruby%20%E5%9B%BD%E5%86%85%E6%BA%90")

hhhhh