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

Question

的实现在其参数不是关联集合时返回 。

此行为可能会掩盖常见的编程错误，例如


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

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


在既不是 也非关联集合的某个对象上调用 几乎一定是错误，应该通过异常来指示。

CLJ-932 被接受为类似于 的增强

补丁：0003-CLJ-1107-Throw-exception-for-get-on-unsupported-type.patch

方法：在 RT.getFrom 中的最后一级抛出 IllegalArgumentException 而不是返回 nil。

另请参阅：CLJ-969

Answer 1

评论由：richhickey 提出

这将是一个破坏性更改

Answer 2

即使 的初始设计可能是混淆的/错误的，现在已经太迟更改了。这种更改不值得。会破坏太多的程序/库。
我们现在能做得更好的是创建一个具有这种新行为的 或 。

此外，我也无法说这个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日之间的提交之后不再适用。我尚未检查更新这个补丁可能有多难或有多容易。

Answer 5

评论者：stuart.sierra

从5cc167a版本的master创建了一个新补丁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吗？我仍在学习这种语言，而且我不年轻 anymore，无法可靠地记住参数的顺序。因此，我发现避免（get）使用maps更容易。没有它，我可以将map放在第一位或第二位。

Answer 9

评论者：alexmiller

这也可以通过针对"get"的spec来完成。

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难以发现，我想不出有任何有效的用例。