红宝石接球和效率答案

【问题标题】：ruby catch-throw and efficiency红宝石接球和效率
【发布时间】：2012-11-09 03:47:08
【问题描述】：

catch 在 Ruby 中意味着跳出深度嵌套的代码。在 Java 中，例如可以使用 Java 的 try-catch 来处理异常，但它被认为是糟糕的解决方案，而且效率也很低。在用于处理异常的 Ruby 中，我们有 begin-raise-rescue，我认为将它用于其他任务也很昂贵。

Ruby 的catch-throw 真的是比begin-raise-rescue 更有效的解决方案吗？还是有其他理由使用它来打破嵌套块而不是begin-raise-rescue？

【问题讨论】：

如果您发布一些您所询问的控制结构的 ruby 示例，您的意思可能会更清楚。

标签： ruby performance try-catch throw control-structure

【解决方案1】：

Josh's answer 是正确的。我想添加更多关于catch-throw 和raise-rescue 的信息。

catch-throw 用于流控制，而raise-rescue 用于异常/错误处理。不同之处在于：catch-throw（流量控制）不需要backtrace。相信我，主要原因是raise-rescue 在Josh's gist 中运行速度比catch-throw 慢10 倍是raise-rescue 需要很长时间才能创建backtrace 对象。

如果你想raise 没有回溯，使用语法：

raise <type>, <message>, <backtrace>

结帐my gist。 raise without backtrace 比 raise with backtrace 快得多。

2016 年 4 月更新：

我已经更新my gist:

修复了“中断”测试
为较新的 ruby 版本 2.1.8、2.2.4、2.3.0 添加了基准测试结果

【讨论】：

【解决方案2】：

除了是摆脱控制结构的“正确”方式之外，catch-throw 的速度也明显加快（在我的测试中是 10 倍）。查看this gist 了解我的代码和结果。

【讨论】：

谢谢！基准测试确实解决了这个问题（在我的情况下，它几乎是 15 倍！）。 catch-throw 是否应该被视为一种结构化的编程风格——一种比 goto 更好的做法？
这是你的设计需要接球，可能有更好的设计。话虽如此，在某些极端情况下，catch throw 很有意义，尤其是在 gem 开发中，您不知道最终用户将如何使用它。
感谢所有解释！