改善使用错误参数数量调用关键字时的错误信息

Question

当您使用错误数量的参数调用关键字时，错误信息未报告传递了多少参数

(:kw "one" "two" "three") => java.lang.IllegalArgumentException: 向关键字传入错误数量的参数：:kw

比较调用一个{{IFn}}，它确实显示了传递的参数数量

(name "one" "two" "three") => clojure.lang.ArityException: 传递给 core/name 的参数数量错误（3）

后者错误信息更清晰，并使调试更简单。

附带的补丁重新使用了在其他地方用于生成错误信息的{{ArityException}}类，在调用关键字时使用后者形式生成错误信息。

解决 CLJ-1067

修复： keyword-arity-exception-03.patch

审查： Alex Miller

Answer 1

评论者：marc

修改错误：later => latter。

Answer 2

评论者：ataggart

+100alık hata mesajlarının iyileştirilmesi için.

尽管可能性不大，因为 throwArity() 是一个公开方法，移除它可能导致外部代码出现问题。

其次，生成的句子有三个冒号，看起来有点尴尬。
"传递给: 关键字: :my.ns/foo 的参数数量错误（3）"

或者
"传递给: 关键字 :my.ns/foo 的参数数量错误（3）"
"传递给: :my.ns/foo 的参数数量错误（3）"

后者与非关键字函数调用的结果相似。
"传递给: my.ns/bar 的参数数量错误（3）"

Answer 3

alexmiller发表的评论：

此外，测试中的 artity-exceptions 确实有拼写错误。

我同意亚历山大的评论，应保留现有的 throwArity()。

Answer 4

评论者：marc

附上更新的补丁。

Answer 5

评论者：marc

我已经附上一个更新的补丁，它修复了 {{deftest}} 声明中的类型，并且以亚历山大建议的方式格式化异常消息。

亚历克斯 - 我需要添加一个 Java 注释来说明 Keyword.throwArtity() 的 0-参数版本存在的原因吗？比如：

/** @deprecated CLJ-2350 此函数不再被调用，但其内容未被删除以保持公共接口。 */

反思公共接口，也许我们可以将新的函数，{{throwArity(int n)}}, 设为包私有。这将避免使其成为 {{clojure.lang}} 的公共 API 的一部分。

Answer 6

alexmiller发表的评论：

是的，是的

Answer 7

评论者：marc

已添加补丁，使 {{throwArity(int)}} 包私有，并添加了弃用文档字符串。

Answer 8

alexmiller发表的评论：

最终的调用作为最后一个参数接受一个变长参数，所以它的实际上是21+，并不是21。可以计算参数数组。补丁已经从master分离，需要重新合并。

Answer 9

评论者：marc

添加了补丁，改善了21个以上参数情况下的错误消息。

Answer 10

评论者：marc

代码中还有两个地方在21个以上参数情况下存在相同的错误。

https://github.com/clojure/clojure/blob/71511b7800e18c83377a322f43585a853b303698/src/jvm/clojure/lang/RestFn.java#L4078
https://github.com/clojure/clojure/blob/71511b7800e18c83377a322f43585a853b303698/src/jvm/clojure/lang/AFn.java#L140

您需要额外的补丁来覆盖这些情况吗？

Answer 11

alexmiller发表的评论：

当然，但需要单独的工单。

Answer 12

评论者：marc

嗨Alex，这个工单有什么更新吗？我已经按照要求更新了补丁到最新的master分支，所以现在应该可以合并了。

Answer 13

评论者：alexmiller

我会在下一次轮到的时加及此事。

Answer 14

评论者：marc_

嗨Alex，

这个工单有什么更新吗？我急于避免再次对master分支的补丁进行rebase。

马克

Answer 15

alexmiller发表的评论：

我已经审查了，但我不确定我们会看1.10的这个问题。如果需要，我会重塑的，没什么大不了的。