How to avoid NoMethodError for missing elements in

2019-01-01 07:37发布

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?

16条回答
低头抚发
2楼-- · 2019-01-01 07:56

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 on params is not actually safe as params.dig will fail if params 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)

查看更多
余生无你
3楼-- · 2019-01-01 07:57

If it's rails, use

params.try(:[], :company).try(:[], :owner).try(:[], :name)

Oh wait, that's even uglier. ;-)

查看更多
心情的温度
4楼-- · 2019-01-01 07:57

(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):

begin
    name = params[:company][:owner][:name]
rescue
    #if it raises errors maybe:
    name = 'John Doe'
end
查看更多
十年一品温如言
5楼-- · 2019-01-01 07:58

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:

查看更多
笑指拈花
6楼-- · 2019-01-01 08:00

Equivalent to the second solution that user mpd suggested, only more idiomatic Ruby:

class Hash
  def deep_fetch *path
    path.inject(self){|acc, e| acc[e] if acc}
  end
end

hash = {a: {b: {c: 3, d: 4}}}

p hash.deep_fetch :a, :b, :c
#=> 3
p hash.deep_fetch :a, :b
#=> {:c=>3, :d=>4}
p hash.deep_fetch :a, :b, :e
#=> nil
p hash.deep_fetch :a, :b, :e, :f
#=> nil
查看更多
查无此人
7楼-- · 2019-01-01 08:00

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.

h = {1 => 'one'}
h.instance_eval %q{
  alias :brackets :[]
  def [] key
    if self.has_key? key
      return self.brackets(key)
    else
      h = Hash.new
      h.default = {}
      return h
    end
  end
}

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.

module AVHash
  def deep(*args)
    first = args.shift
    if args.size == 0
      return self[first]
    else
      if self.has_key? first and self[first].is_a? Hash
        self[first].send(:extend, AVHash)
        return self[first].deep(*args)
      else
        return nil
      end
    end
  end
end      

h = {1=>2, 3=>{4=>5, 6=>{7=>8}}}
h.send(:extend, AVHash)
h.deep(0) #=> nil
h.deep(1) #=> 2
h.deep(3) #=> {4=>5, 6=>{7=>8}}
h.deep(3,4) #=> 5
h.deep(3,10) #=> nil
h.deep(3,6,7) #=> 8

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.

查看更多
登录 后发表回答