'get'在非关联参数上应抛出异常

Question

{{clojure.core/get}}的实现在其参数不是关联集合时返回{{nil}}。

这种行为可能会导致如下的常见程序员错误


(def a (atom {:a 1 :b 2}))

(:foo a)   ; 忘记 deref a
;;=> nil


在既不是{{nil}}也不是关联集合的某物上调用{{get}}几乎肯定是一个错误，应通过异常来表示。

CLJ-932被接受作为对{{clojure.core/contains?}}的类似增强。

*修补程序:* 0003-CLJ-1107-Throw-exception-for-get-on-unsupported-type.patch

*方法:* 在RT.getFrom中，将IllegalArgumentException作为最终的回退情况抛出，而不是返回{{nil}}。

*另请参阅:* CLJ-969

Answer 1

评论人：richhickey

这将是一个破坏性变更

Answer 2

即使clojure.core/get的初始设计很令人困惑/错误，现在也改不了了。这种变更不值得，会破坏太多程序/库。
我们现在能做的最好的事情是为具有这种新行为的创建一个clojure.core/get2或my-lib.core/get。

此外，我不能说这个get2的行为比我们的get更好/正确。它只是get的另一套规则。您提出这套新规则，是否有什么保证，在另有一天，不会有人出现并提出一套新的get规则？比如一个get3？您怎么知道何时停止呢？

Answer 3

评论由：jafingerhut

2013年5月24日创建的补丁clj-1107-throw-on-get-for-unsupported-types-patch-v2.txt与2012年11月13日创建的0001-CLJ-1107-Throw-exception-for-get-called-on-unsupport.patch相同，区别在于它对最新的master版本进行了干净的应用。CLJ-1099的最近提交将测试中许多IllegalArgumentException转换为Throwable，这是此更新修补程序中唯一更改的内容。

Answer 4

评论由：jafingerhut

补丁clj-1107-throw-on-get-for-unsupported-types-patch-v2.txt已于2014年1月23日干净地应用于最新的Clojure master版本，但在2014年1月30日到那时之间对Clojure所做的提交中不再适用。我还没有检查更新这个补丁可能有多难或有多容易。

Answer 5

评论由：stuart.sierra

从master版本5cc167a创建的新补丁0003-CLJ-1107-Throw-exception-for-get-on-unsupported-type.patch

Answer 6

评论由：jafingerhut

2014年3月26日发布的补丁clj-1107-throw-on-unsupported-get-v4.patch与Stuart Sierra的补丁0003-CLJ-1107-Throw-exception-for-get-on-unsupported-type.patch相同，保留了其作者身份。唯一的区别在于diff上下文中的一行，这是为了使其能够干净地应用于最新的master版本。

Answer 7

_评论由：stuart.sierra_

可以说CLJ-932（{{contains?}}）也是这样的，它“打破”了一些已经出错的东西。

这次更改比CLJ-932更具侵入性，但我认为它更有可能暴露隐藏的bug，而不是破坏有意为之的行为。

Answer 8

_评论由：alex+import_ 发表

使用"({:a 1}, :a)"和安全的替换器启动更为直观吗？例如，能否在代码库中大量替换"(get "为"(")，以寻找bug？我还在学习这门语言，而且年纪也不小了，所以 unreliable 记得参数顺序。所以，我发现在没有(get)的情况下，使用映射要容易得多。没有它，我可以将映射放在第一或第二位。

Answer 9

评论者：alexmiller

假设现在也可以通过在"get"上的规格来实现这一点。

Answer 10

参考：https://clojure.atlassian.net/browse/CLJ-1107 （由 stuart.sierra 报告）

Answer 11

我原以为(get m k)等同于(val (find m k))，但m不是关联型时则并非如此，这让我非常惊讶。

当m不是关联型时，find 生成一个异常，但get 只返回nil。

我认为get也应该在第一个参数不是关联型时抛出异常。
对于非关联型的参数返回nil将只会遮蔽bug，我想不出任何有效的情况。