避免在访问子元素时检查是否为nil

Question

这可能是一个比较表面的问题，但我觉得它真的很烦人，因为最终总是会出现一些丑陋的代码。而可读性始终很重要，对吧？

我想检查一个哈希内是否存在另一个哈希中的值。所以我做的就是这样。

already_exists_data[:data][:user_id]

但是如果:data为nil，那么我可能会得到一个nullpointer异常，而检查：data可能会给我一个nullpointer，如果already_exists_data为nil。所以我最终得到的是这个：

if already_exists_data && already_exists_data[:data] && already_exists_data[:data][:user_id]
    # Do stuff
end

这是一些难看的代码。也许我应该将哈希修改为对象。但有时候我还是会遇到这个问题，想知道你们是如何解决它的。

我目前在使用Ruby编程，但我在其他多种语言中也遇到了类似的问题。

- softarn

Answer 1

如果我让我的管家去拿在维多利亚街34号餐厅桌子上的巧克力盒子，我就只会这样说。我不想说：去找维多利亚街，如果你找到了，请找34号，如果你找到了... 我之所以能这么做是因为他会自己纠正错误：如果他找不到街道，他就会空手而归。

所以你应该使用一个带有空异常处理程序的try。伪代码如下：

try {chocolates = streets("Victoria")(34)("dining room")("table")}

在一些（比如Ruby）块是表达式的语言中，你可以写成这样：

if try {already_exists_data(data)(user_id)}

do_stuff

语言本身也可以帮助：在Perl中，例如当$streets未定义时，$streets{Victoria}[34]{dining_room}{table}也是未定义的。当然，在你发现地址错误之前，你的管家可能会空手而归多年。使用try块解决方案和if .. && ....也有同样的缺点：只有在你真的不关心Victoria Street是否有34号时才使用它们。

- Hans Lub

Answer 2

与语言无关的解决方案：永远不要使用 null。在整个项目中强制执行此规则。如果您确实需要使用 null，则应该将它们包装成Either/Optional以增加明确性。一些语言，如Scala，已经内置了Optional的概念。

Java特定的解决方案：如果必须使用 null，请使用@Nullable和@Nonnull注释方法参数和返回值。像IntelliJ这样的良好IDE能够分析您的代码并突出显示可能的null引用，如果从这样的方法获取值。

- mindas

Answer 3

另一种可能性是将哈希访问包装在函数调用中，并在函数内部完成“脏”工作。然后你的代码将类似于（伪代码语法）：

accessHash(already_exists_data, data, userid)

注意：您可以根据传递给包装函数的参数数量访问嵌套哈希，以便它在多种情况下都能正常工作。

- Attila