ruby - 为什么我们应该避免以其修饰符形式使用 rescue？

Question

我会定义值(value)。但是这个值可能在散列的键值中。如果此键不存在，我将使用 rescue 定义值为 nil。例如

foo = bar[:a][:b][:c] 救援 nil

但在实践中告诉我糟糕的风格，因为我在其修饰符形式中使用了 rescue。我将更改逻辑以使用检查三个条件。

foo = bar[:a][:b][:c] if bar.key?(:a) && bar[:a].key?(:b) && bar[:a][ :b].key?(:c)

我真的很想知道为什么我们应该避免使用修饰符形式的 rescue？

Answer 1

Why should we avoid using rescue in its modifier form in rails?

首先，因为它隐藏了所有错误，包括你预料到的和你没有预料到的，而且一揽子救援并不能使 future 变得清晰您的代码的读者哪些错误是预期的或意外的。这可能不是问题现在，使用简单的foo[:a][:b][:c]，但在任何给定的时间点，有人可能会修改它读取 foo[:a][:b][some_method] 的语句，突然间 应该 从 some_method 冒出的任何错误也被吞没了。

其次，通常有更好的解决方案，它的设计更明确，只处理您打算忽略的错误:缺少索引或 nil 返回值。

在您的情况下，替代方案不是您建议的大量if && && &&。对于哈希，您可以使用 dig ，它具有 rescue 的所有好处，而不会吞没可能引发的所有类型的异常:

foo = bar.dig(:a, :b, :c)

类似地，对于链式方法调用，您可以使用 try(在 Rails 中)或安全导航运算符(在 Ruby 2.3 中):

foo = bar.try(:a).try(:b).try(:c)
# or
foo = bar&.a&.b&.c