当将非seq传递给seq时的更错误信息

Question

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

此补丁改善了Clojure对单个常见错误的错误信息：在不应为seq的地方传递非seq。更重要的是，它被设计成为未来其他类似改进的原型。

错误信息之前


(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并了解如何使用它？
许多初学者将无法找到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 文字：“faux协议”调用具有类似失败的分支）情况下，以类似的方式提取ex构造函数可能带来1)更好的错误数据，2)更小的方法体

Answer 5

评论者：admin

我愿意重新审视它——新的补丁导致许多测试失败，因此需要修复才能筛选。更愿意看到使测试对消息文本更不敏感的更改。

Answer 6

引用：https://clojure.atlassian.net/browse/CLJ-1099 (由stu报告)