这可能是一个更美观的问题，但我发现它真的很烦人，因为我总是得到一些丑陋的代码。可读性总是很重要的，对吧？
我想检查一个值是否存在于散列中的散列中。所以我要做的就是这个。
already_exists_data[:data][:user_id]
但是如果 :data 为 nil 并且检查 :data 可能会给我一个 nullpointer 异常，如果 already_exists_data 为 nil。所以我最终得到的是：
if already_exists_data && already_exists_data[:data] && already_exists_data[:data][:user_id]
# Do stuff
end
现在这是一些看起来很讨厌的代码。也许我应该将哈希修改为一个对象。但我有时会碰到这个问题，想知道你们是如何面对它的。
我目前正在使用 Ruby 进行编码，但我在使用多种其他语言时遇到了这个问题。
如果我让管家在维多利亚街 34 号的餐桌上拿起一盒巧克力，我只会这样问他。我不想说：去找维多利亚街，如果找到了，请找34号，如果找到了……
我能做到这一点是因为他发现了自己的错误：如果他找不到那条街，他就会空手而归。
因此，您应该使用try带有空异常处理程序的 a 。在伪代码中：
试试 {chocolates = street("Victoria")(34)("dining room")("table")}
在语言中（例如ruby，带有一些朴素的语法糖），块是您可以编写的表达式：
如果尝试 {already_exists_data(data)(user_id)}
做东西
语言本身也可以提供帮助： in perl,$streets{Victoria}[34]{dining_room}{table}当 eg 是时未定义$streets。当然，在您发现地址错误之前，您的管家可能会空手而归。try块解决方案 - 和您的-if .. && ....具有相同的缺点：仅当您真的不在乎 Victoria Street 是否有 34 号时才使用它们。
与语言无关的解决方案：不要使用空值。曾经。在您的项目中强制执行此规则。如果您绝对必须，请将它们包装到Either/Optional中，这会增加明确性。一些语言，比如 Scala，有Optional已经内置的概念。
特定于 Java 的解决方案：如果必须使用 null，请使用 和 注释方法参数和返回@Nullable值@Nonnull。null如果从这种方法获取值，体面的 IDE（例如 IntelliJ）能够分析您的代码并突出显示可能的取消引用。
另一种可能性是用函数调用包装散列访问，并在函数内执行“脏”工作。然后您的代码将类似于（伪代码语法）：
accessHash(already_exists_data, data, userid)
注意：您可以根据传递给包装函数的参数数量来访问嵌套哈希，因此它适用于多种情况。