当调用具有错误参数数量的关键词时改善错误信息

Question

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

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

比较调用Fcn，这显示了传递的参数数量

(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

+100 为改进错误信息。

尽管可能性不大，因为 throwArity() 是一个公开的方法，移除它可能会破坏外部代码。

其次重要的是，由于三个冒号，生成的句子看起来有点不自然
"传递给关键字的参数数量不正确（3）: 关键字: :my.ns/foo"

或者
"传递给关键字的参数数量不正确（3）: 关键字 :my.ns/foo"
"传递给: :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。可以计算参数数组。补丁已与主分支不同步，需要重新合并。

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

_made by: alexmiller_

下次迭代时我将处理这个问题。

Answer 14

_made by: marc_

嗨Alex，

这个条目有什么更新吗？我迫不及待想避免再次将补丁与master合并。

Marc

Answer 15

评论者：alexmiller

我已经筛选过了， but 我不确定我们是否会在1.10版本中查看它。如果需要，我会重新合并，没什么大不了的。