当向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存在并提供相应的方式来使用它？

Answer 2

评论者：stu

嗨，Michael，

ex-info消息通常不应该将东西打印出来作为它们的正文。这会引发有关print-length和print-level的问题，用户在一个他们没有良好控制的地方打印，而ex-info的整个点是在数据业务，而不是字符串业务。用户可以通过任何方式从ex-data中控制打印。

有两种可能的方式让初学者了解ex数据：在文档中的一个（或几个地方）提到了它，或者在无数个地方说“这里本来会用得上，但因为我们不确定你是否知道，所以我们没有使用它。”我更喜欢前者。

然而，我认为最好增加文档中对于初学者来说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报告）