当传递非序列给序列时提供更好的错误信息

Question

设计讨论[这里|http://dev.clojure.org/display/design/Better+Error+Messages].

此补丁改善了Clojure对单个常见错误的错误信息：需要对序列传递非序列。更重要的是，它被旨在作为未来其他类似改进的原型。

之前的错误信息


(cons 1 2)
=> IllegalArgumentException 无法从：java.lang.Long创建ISeq


之后的错误信息


user=> (cons 1 2)
ExceptionInfo 无法从：java.lang.Long创建ISeq
user=> (ex-data *e)
{:instance 2}


*补丁:* better-error-message-for-seq.patch
注意：此补丁已回滚，因为它影响了RT.seqFrom()的内联。

Answer 1

评论由：michaelklishin 提出

是否最好将其改为“无法从：2 (java.lang.Long)创建ISeq”？有多少初学者能弄清楚ex-data的存在以及如何使用它？
?

Answer 2

评论由：stu 提出

嗨，Michael，

ex-info消息通常不应将pr-str打印到它们的主体中。这引发了一个问题：在用户没有良好控制的地方提高print-length和print-level，而ex-info的整个点在于数据业务，而不是字符串业务。用户可以像他们喜欢的方式从ex-data控制打印。

让初学者了解ex-data有两种可能的方法：在一处（或几处）文档中告诉他们，或者在无限多的地方说“如果在这里使用将会很方便，但我们没有使用它是因为你可能不知道。”我比较偏好前者。

话虽如此，我认为在文档中尽早提高ex-info和ex-data的可见性会很不错，并确保诸如日志中异常打印的东西足够灵活，以免丢失ex-info的好处。

Answer 3

评论者：jafingerhut

这只是条注释，这个修复在1.6.0版本发布之前就已经提交，然后在发布1.6.0之前很短的时间内被回滚。我相信回滚的原因是出于担心这个更改在某些相对常见的情况下使性能降低了大约5%，并怀疑它可能影响了seqFrom方法的内联。

不清楚这个工单是否应该重新打开。

Answer 4

评论者：gshayban

我认为现在可以重新审视这个。原始补丁将seqFrom方法的大小从133字节改为152字节（链接：https://groups.google.com/d/msg/clojure/K6W7DbxV0Cw/N3onXKkFVX8J），（如在此处讨论的那样）会影响内联。如果我们像（链接：^{^CLJ-1099-better-error-message.txt}）中那样将异常构建移到方法中，该方法就变成100字节。

还有一类（链接：https://github.com/clojure/clojure/blob/8c402a8c9695a4eddc07cbbe0d95d44e1372f0bf/src/jvm/clojure/lang/RT.java#L853）的调用，即“假协议”调用，以一种类似的方式提取ex构建函数，可能会导致1）更好的错误与错误数据 2）更小的方法体

Answer 5

评论者：admin

我将很高兴重新审视 - 新的补丁导致许多测试失败，所以这需要修复才能过筛。更倾向于使它们对消息文本不那么脆弱的测试更改。

Answer 6

参考：https://clojure.atlassian.net/browse/CLJ-1099（由 stu 报告）