为什么安全导航比在 Rails 中使用 try 更好? [英] Why is safe navigation better than using try in Rails?
问题描述
我正在阅读这个.使用它有什么好处:
I'm reading this. What's the benefit of using this:
user&.address&.state
结束
user.try(:address).try(:state)
我还是不明白.
推荐答案
(1) &. 一般比 try(...)
短>根据场景，这可以使您的代码更具可读性.
(1) &. is generally shorter than try(...)
Depending on the scenario, this can make your code more readable.
方法 try 不是在 Ruby 核心库中定义的，而是在 Rails 库中定义的.当您不是在开发 RoR Web 应用程序而是在编写例如小助手脚本，这将很快变得相关.(例如，我更喜欢 Ruby 而不是 Bash.)
The method try is not defined in a Ruby core library but rather in a Rails library. When you are not developing a RoR web app but instead are writing e.g. little helper scripts, this will get relevant pretty fast.
(I prefer Ruby over Bash, for example.)
如果调用了不存在的方法，安全遍历运算符将抛出错误.
The safe traversal operator will throw an error if a nonexistent method is being invoked.
>> "s"&.glubsch
NoMethodError: undefined method `glubsch' for "s":String
只有在 nil 上它才会表现的很宽容:
Only on nil it will behave leniently:
>> nil&.glubsch
=> nil
try 方法将始终返回 nil.
>> "s".try(:glubsch)
=> nil
请注意，最新版本的 Ruby 和 Rails 就是这种情况.
Note that this is the case with most recent versions of Ruby and Rails.
现在想象一个场景，其中存在一个名为 glubsch 的方法.然后您决定重命名该方法，但忘记在一个地方重命名它.(遗憾的是，这可能发生在 ruby 中......)使用安全遍历运算符，您几乎会立即注意到错误(第一次执行该行代码时).然而，try 方法会很高兴地为您提供一个 nil 并且您将在程序执行的下游某处收到一个与 nil 相关的错误.有时很难弄清楚这样一个 nil 的来源.
Now imagine a scenario where a method named glubsch exists. Then you decide to rename that method but forget to rename it in one place. (Sadly, that can happen with ruby...) With the safe traversal operator, you will notice the mistake almost immediately (as soon as that line of code is executed for the first time). The try method however will happily provide you with a nil and you will get a nil related error somewhere downstream in program execution. Figuring out where such a nil came from can be hard at times.
使用 &. 快速而艰难地失败使调试比使用 try 轻松返回 nil 更容易.
Failing fast and hard with &. makes debugging easier than blithely returning nil with try.
还有一个变体 try!(有爆炸声)，其行为与 &. 相同对此.如果您不喜欢 &.，请使用它.
There is also the variant try! (with a bang) that behaves the same as &. in this regard. Use that if you don't like &..
那会很奇怪.由于这将是一种意想不到的编程方式，请使其明确.例如，通过使用 respond_to? 充实这两种情况(已实施或未实施)并从中分支出来.
That would be strange. Since that would be an unexpected way of programming, please make it explicit. For example by fleshing out the two cases (implemented or not) using respond_to? and branch off of that.
可以将块传递给 try 来代替方法名称.该块将在接收者的上下文中执行；并且在该区块内不适用宽大处理.因此，只需调用一个方法，它的行为就与 &. 相同.
Instead of a method name, a block can be passed to try. The block will be executed in the context of the receiver; and within the block there is no leniency applied. So with just a single method call, it will acutally behave the same as &..
>> "s".try{ glubsch }
NameError: undefined local variable or method `glubsch' for "s":String
对于更复杂的计算，与引入大量局部变量相比，您可能更喜欢这种块形式.例如.一串
For more complex computations, you might prefer this block form over introducing lots of local variables. E.g. a chain of
foo.try{ glubsch.blam }.try{ bar }.to_s
允许 foo 为 nil 但要求 foo.glubsch 返回一个非 nil 值.再说一次，您可以以更简洁的方式对安全遍历运算符执行相同操作:
would allow foo to be nil but require foo.glubsch to return a non-nil value. Then again, you can do the same with the safe traversal operator in a more concise fashion:
foo&.glubsch.blam&.bar.to_s
使用 try 的块形式进行复杂计算恕我直言是一种代码异味，因为它妨碍了可读性.当你需要实现复杂的逻辑时，引入具有描述性名称的局部变量，并可能使用 if 来分支 nil 案例.您的代码将更易于维护.
Using try's block form for complex computations IMHO is a code smell, though, because it impedes readability. When you need to implement complex logic, introduce local variables with descriptive names and maybe use an if to branch off a nil case. Your code will be more maintainable.
HTH！
这篇关于为什么安全导航比在 Rails 中使用 try 更好?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
