如何避免嵌套哈希中缺少元素的 NoMethodError,而不需要重复的 nil 检查?
我正在寻找一种好方法来避免在深度嵌套哈希中的每个级别检查 nil
。例如:
name = params[:company][:owner][:name] if params[:company] && params[:company][:owner] && params[:company][:owner][:name]
这需要三项检查,并且代码非常难看。有办法解决这个问题吗?
I'm looking for a good way to avoid checking for nil
at each level in deeply nested hashes. For example:
name = params[:company][:owner][:name] if params[:company] && params[:company][:owner] && params[:company][:owner][:name]
This requires three checks, and makes for very ugly code. Any way to get around this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(16)
危险但有效:
我们可以新做
“h_try”链遵循与“try”链类似的风格。
Dangerous but works:
We can new do
The "h_try" chain follows similar style to a "try" chain.
太长了;
params&.dig(:company, :owner, :name)
从 Ruby 2.3.0 开始:
您还可以使用称为“安全导航运算符”的
&.
作为:params&.[](:公司)&.[](:所有者)&.[](:名称)
。这个是绝对安全的。在
params
上使用dig
实际上并不安全,因为如果params
为 nil,params.dig
将失败。不过,您可以将两者组合为:
params&.dig(:company, :owner, :name)
。因此,以下任一选项都可以安全使用:
params&.[](:company)&.[](:owner)&.[](:name)
params&.挖掘(:公司,:所有者,:名称)
TLDR;
params&.dig(:company, :owner, :name)
As of Ruby 2.3.0:
You can also use
&.
called the "safe navigation operator" as:params&.[](:company)&.[](:owner)&.[](:name)
. This one is perfectly safe.Using
dig
onparams
is not actually safe asparams.dig
will fail ifparams
is nil.However you may combine the two as:
params&.dig(:company, :owner, :name)
.So either of the following is safe to use:
params&.[](:company)&.[](:owner)&.[](:name)
params&.dig(:company, :owner, :name)
只是为了提供
dig
上的一个,请尝试 KeyDial 我写的 gem。这本质上是dig
的包装器,但重要的区别是它永远不会给您带来错误。如果链中的对象属于某种本身无法被挖掘的类型,那么挖掘仍然会抛出错误。
在这种情况下,
dig
对您没有帮助,您不仅需要返回到hash[:a][:d].nil? &&
还进行hash[:a][:d].is_a?(Hash)
检查。 KeyDial 可以让您在没有此类检查或错误的情况下执行此操作:Just to offer a one-up on
dig
, try the KeyDial gem which I wrote. This is essentially a wrapper fordig
but with the important difference that it will never hit you with an error.dig
will still spit out an error if an object in the chain is of some type that can't itself bedig
ed.In this situation
dig
does not help you, and you need to go back not only tohash[:a][:d].nil? &&
but alsohash[:a][:d].is_a?(Hash)
checks. KeyDial lets you do this without such checks or errors:Ruby 2.3.0 引入了名为
dig
的方法 在Hash
和Array
上。如果任何级别的密钥丢失,它都会返回
nil
。如果您使用的 Ruby 版本早于 2.3,则可以安装 ruby_dig 或 hash_dig_and_collect 等 gem,或自行实现该功能:
Ruby 2.3.0 introduced a method called
dig
on bothHash
andArray
.It returns
nil
if the key is missing at any level.If you are using a version of Ruby older than 2.3, you can install a gem such as
ruby_dig
orhash_dig_and_collect
, or implement the functionality yourself:在我看来,功能性和清晰度之间的最佳折衷方案是 Raganwald 的
andand
。这样,您就可以这样做:它与
try
类似,但在这种情况下读起来更好,因为您仍然像平常一样发送消息,但之间有一个分隔符,以引起人们注意这样一个事实:我们正在特别对待尼尔斯。The best compromise between functionality and clarity IMO is Raganwald's
andand
. With that, you would do:It's similar to
try
, but reads a lot better in this case since you're still sending messages like normal, but with a delimiter between that calls attention to the fact that you're treating nils specially.我不知道这是否是你想要的,但也许你可以做到这一点?
I don't know if that's what you want, but maybe you could do this?
您可能想研究将 auto-vivification 添加到 ruby 哈希的方法之一。以下 stackoverflow 线程中提到了多种方法:
You may want to look into one of the ways to add auto-vivification to ruby hashes. There are a number of approaches mentioned in the following stackoverflow threads:
相当于用户
mpd
建议的第二个解决方案,只是更惯用的 Ruby:Equivalent to the second solution that user
mpd
suggested, only more idiomatic Ruby:更新:这个答案已经过时了。按照当前接受的答案建议使用
dig
。如果是Rails,请使用
哦等等,那更难看。 ;-)
Update: This answer is way out-of-date. Use
dig
as the current accepted answer suggests.If it's Rails, use
Oh wait, that's even uglier. ;-)
如果你想进入猴子补丁,你可以这样做
<代码>
然后,如果任何时候嵌套哈希值之一为 nil,则对 params[:company][:owner][:name] 的调用将产生 nil。
编辑:
如果您想要一条更安全的路线,同时提供干净的代码,您可以这样做
<代码>
代码如下所示:
params.chain(:company, :owner, :name)
If you wanna get into monkeypatching you could do something like this
Then a call to
params[:company][:owner][:name]
will yield nil if at any point one of the nested hashes is nil.EDIT:
If you want a safer route that also provides clean code you could do something like
The code would look like this:
params.chain(:company, :owner, :name)
我会这样写:
它不像 那样干净? Io 中的运算符,但 Ruby 没有。 @ThiagoSilveira 的答案也很好,尽管会慢一些。
I would write this as:
It's not as clean as the ? operator in Io, but Ruby doesn't have that. The answer by @ThiagoSilveira is also good, though it will be slower.
您是否能够避免使用多维哈希并使用
or
代替?
Are you able to avoid using a multi-dimensional hash, and use
or
instead?
把丑陋写一次,然后隐藏起来
Write the ugliness once, then hide it
(尽管这是一个非常老的问题,也许这个答案对于像我这样没有想到“开始救援”控制结构表达式的一些 stackoverflow 人来说会很有用。)
我会用 try catch 语句来做到这一点(用 ruby 语言开始救援):
(Even though it's a really old question maybe this answer will be useful for some stackoverflow people like me that did not think of the "begin rescue" control structure expression.)
I would do it with a try catch statement (begin rescue in ruby language):
做:
同样,在每一步中,如果它是数组、字符串或数字,您都可以使用
NilClass
中内置的适当方法来转义nil
。只需将to_hash
添加到此列表的清单中并使用它即可。Do:
Also at each step, you can use an appropriate method built in
NilClass
to escape fromnil
, if it were array, string, or numeric. Just addto_hash
to the inventory of this list and use it.您不需要访问原始哈希定义 - 您可以在使用 h.instance_eval 获取它后即时重写 [] 方法,例如
但这不会帮助您处理您拥有的代码,因为您依赖未找到的值返回错误值(例如,nil),如果您执行上面链接的任何“正常”自动激活操作,您最终会得到未找到值的空散列,其计算结果为“真的”。
你可以这样做——它只检查定义的值并返回它们。你不能这样设置它们,因为我们无法知道调用是否在分配的 LHS 上。
但同样,您只能用它检查值,而不能分配它们。所以这并不是我们在 Perl 中所知道和喜欢的真正的自动激活。
You don't need access to the original hash definition -- you can override the [] method on the fly after you get it using h.instance_eval, e.g.
But that's not going to help you with the code you have, because you're relying on an unfound value to return a false value (e.g., nil) and if you do any of the "normal" auto-vivification stuff linked to above you're going to end up with an empty hash for unfound values, which evaluates as "true".
You could do something like this -- it only checks for defined values and returns them. You can't set them this way, because we've got no way of knowing if the call is on the LHS of an assignment.
Again, though, you can only check values with it -- not assign them. So it's not real auto-vivification as we all know and love it in Perl.