当将非序列传递给序列时获得更好的错误信息

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消息不应该将其body中的东西pr-str。这会引发print-length和print-level在用户无法很好地控制的地方。而ex-info的whole point是处理数据业务，而不是字符串业务。用户可以从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，文本：“faux 协议”调用与类似的失败分支）通过类似的方法提取 ex 构造函数可以导致 1) 通过错误数据提供更好的错误信息 2) 更小的方法体

Answer 5

评论者：admin

我很乐意重新审视这个问题 - 新补丁导致许多测试失败，因此需要进行修复，以便进行筛选。建议选择那些使测试对消息文本不那么脆弱的测试更改。

Answer 6

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