当将非序列传递给序列时的更佳错误信息

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 吗？" 有多少初学者能 figure outsourcing 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字节（链接：[此处省略链接]）。如果我们像（链接：[此处省略链接]）那样将异常构造移动到一个方法中，方法就会变成100字节。

还有一类（链接：[此处省略链接]的“faux协议”调用，以类似的方式提取ex构造函数可能带来以下好处：1）更好的错误与错误数据相关联；2）更小的方法体。

Answer 5

评论者：admin

我很乐意重新审视这个问题——新的修正导致许多测试失败，因此需要修复以进行筛选。更喜欢对消息文本有更少的脆弱性的测试更改。

Answer 6

参考：[此处省略链接]（由stu报告）