Ruby 为什么安全导航比在 Rails 中使用 try 更好

(1) &. is generally shorter than try(...)

根据场景的不同，这可以使代码更具可读性.

(2) &. is standard Ruby, as opposed to try

方法try不是在Ruby核心库中定义的，而是在Rails库中定义的.当你不是在开发RoR web应用程序，而是在编写小助手脚本时，这会很快变得相关.

(3) &. makes debugging easier

如果调用了不存在的方法，安全遍历操作符将抛出错误.

>> "s"&.glubsch
NoMethodError: undefined method `glubsch' for "s":String

只有在nil岁时，它才会表现得宽大:

>> nil&.glubsch
=> nil

try方法将始终返回nil.

>> "s".try(:glubsch)
=> nil

请注意，最新版本的Ruby和Rails就是这样.

现在想象一个场景，其中存在一个名为glubsch的方法.然后决定重命名该方法，但忘记在一个地方重命名它.(遗憾的是，ruby可能会出现这种情况……)使用安全遍历操作符，您几乎会立即注意到错误(只要该行代码第一次执行).然而，try方法很乐意为您提供一个nil，并且您将在程序执行的下游某处得到一个与nil相关的错误.有时，弄清楚这样一个nil的来源可能很困难.

用&.快速而艰难地失败比用try轻松地返回nil更容易调试.

EDIT: There is also the variant try! (with a bang) that behaves the same as &. in this regard. Use that if you don't like &..

(4) 如果我不在乎是否实现了一个方法呢？

那太奇怪了.由于这是一种意想不到的编程方式，请明确说明.例如，通过使用respond_to?充实两个 case (实施或未实施)，并将其分支.

(5) What about try's block form?

块可以传递给try，而不是方法名.该块将在接收器的上下文中执行；在街区内，没有宽大处理.因此，只需一个方法调用，它的行为实际上与&.相同.

>> "s".try{ glubsch }
NameError: undefined local variable or method `glubsch' for "s":String

对于更复杂的计算，您可能更喜欢这种块形式，而不是引入大量局部变量.例如，一连串的

foo.try{ glubsch.blam }.try{ bar }.to_s

将允许foo为nil，但要求foo.glubsch返回非nil值.然后，您可以以更简洁的方式使用安全遍历操作符执行同样的操作:

foo&.glubsch.blam&.bar.to_s

然而，在复杂的计算中使用try的块形式是一种代码味道，因为它会妨碍可读性.当你需要实现复杂的逻辑时，可以引入带有描述性名称的局部变量，也可以使用if来区分nil的情况.您的代码将更易于维护.

嗯！