在`ExceptionInfo`构造函数中将空值（nil）作为第二个参数传递...

Question

抛出异常的这一行
https://github.com/clojure/clojure/blob/clojure-1.9.0/src/jvm/clojure/lang/ExceptionInfo.java#L31

由于这个调用
https://github.com/clojure/spec.alpha/blob/spec.alpha-0.1.143/src/main/clojure/clojure/spec/test/alpha.clj#L279

如果`when-not`返回nil，`ExceptionInfo`将在第31行抛出异常。

一个简单的修复可能是
(apply ex-info (remove nil? (link: "基于规范的检查失败" (when-not ...))))

尽管这实际上只是在掩盖问题，并为失败者提供没有可操作信息。

不幸的是，我没有最小测试案例，因为这个是专有（且复杂的）代码。

或许阅读过代码的作者会有更多的见解。

这是完整堆栈跟踪

(link: [clojure.lang.ExceptionInfo "ExceptionInfo.java" 31) (link: clojure.lang.ExceptionInfo "ExceptionInfo.java" 22) (link: clojure.core$ex_info invokeStatic "core.clj" 4739) (link: clojure.core$ex_info invoke "core.clj" 4739) (link: clojure.spec.test.alpha$explain_check invokeStatic "alpha.clj" 277) (link: clojure.spec.test.alpha$explain_check invoke "alpha.clj" 275) (link: clojure.spec.test.alpha$check_call invokeStatic "alpha.clj" 295) (link: clojure.spec.test.alpha$check_call invoke "alpha.clj" 285) (link: clojure.spec.test.alpha$quick_check$fn__2986 invoke "alpha.clj" 308) (link: clojure.lang.AFn applyToHelper "AFn.java" 154) (link: clojure.lang.AFn applyTo "AFn.java" 144) (link: clojure.core$apply invokeStatic "core.clj" 657) (link: clojure.core$apply invoke "core.clj" 652) (link: clojure.test.check.properties$apply_gen$fn__16139$fn__16140 invoke "properties.cljc" 30) (link: clojure.test.check.properties$apply_gen$fn__16139 invoke "properties.cljc" 29) (link: clojure.test.check.rose_tree$fmap invokeStatic "rose_tree.cljc" 77) (link: clojure.test.check.rose_tree$fmap invoke "rose_tree.cljc" 73) (link: clojure.test.check.generators$fmap$fn__9199 invoke "generators.cljc" 101) (link: clojure.test.check.generators$gen_fmap$fn__9173 invoke "generators.cljc" 57) (link: clojure.test.check.generators$call_gen invokeStatic "generators.cljc" 41) (link: clojure.test.check.generators$call_gen invoke "generators.cljc" 37) (link: clojure.test.check$quick_check invokeStatic "check.cljc" 94) (link: clojure.test.check$quick_check doInvoke "check.cljc" 37) (link: clojure.lang.RestFn invoke "RestFn.java" 425) (link: clojure.lang.AFn applyToHelper "AFn.java" 156) (link: clojure.lang.RestFn applyTo "RestFn.java" 132) (link: clojure.core$apply invokeStatic "core.clj" 657) (link: clojure.core$apply invoke "core.clj" 652) (link: clojure.spec.gen.alpha$quick_check invokeStatic "alpha.clj" 29) (link: clojure.spec.gen.alpha$quick_check doInvoke "alpha.clj" 27) (link: clojure.lang.RestFn applyTo "RestFn.java" 137) (link: clojure.core$apply invokeStatic "core.clj" 661) (link: clojure.core$apply invoke "core.clj" 652) (link: clojure.spec.test.alpha$quick_check invokeStatic "alpha.clj" 309) (link: clojure.spec.test.alpha$quick_check invoke "alpha.clj" 302) (link: clojure.spec.test.alpha$check_1 invokeStatic "alpha.clj" 335) (link: clojure.spec.test.alpha$check_1 invoke "alpha.clj" 323) (link: clojure.spec.test.alpha$check$fn__3005 invoke "alpha.clj" 411) (link: clojure.core$pmap$fn__8105$fn__8106 invoke "core.clj" 6942) (link: clojure.core$binding_conveyor_fn$fn__5476 invoke "core.clj" 2022) (link: clojure.lang.AFn call "AFn.java" 18) (link: java.util.concurrent.FutureTask run "FutureTask.java" 266) (link: java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1149) (link: java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 624) (link: java.lang.Thread run "Thread.java" 748)]

Answer 1

评论者：johanatan

因此，我最终追踪到这样一个实际的问题：在我测试函数中返回的函数值对于特定的输入会抛出异常。

此补丁有助于帮助人们找到这个方向（尽管更好的方案应该是展示/解释底层失败，而不仅仅是暗示它）。

Answer 2

评论者：johanatan

有人会回应这个问题吗？通常反馈补丁/拉取请求的预期响应时间是多少？

Answer 3

评论者：alexmiller

此处信息不足以对这项任务采取行动。如果(s/valid? spec 数据)为false，则(s/explain-data spec 数据)永远不应该为nil。你看到这一点表明spec实现中存在bug，但没有更多关于spec或数据的信息，我目前无能为力。

Answer 4

评论者：johanatan

“可采取行动”的部分是提交的补丁。这段代码对受影响的用户更为健壮和友好。

这个任务的实际文本仅仅是原始任务的CLONE（因为我无法重新打开或编辑原始任务）。

Answer 5

评论者：johanatan

换句话说，我提交这个补丁的唯一方法是创建一个CLONE。

Answer 6

评论者：jafingerhut

Jonathan，鉴于你位于Clojure贡献者名单中，我已经提升了你在Clojure JIRA上的权限，因此你现在应该可以编辑工单了。

我不认为有固定的响应时间，这可能会因问题的清晰度和重要性而量级不同。

Alex可能会欣赏如果在描述中包括一个可以复现问题的示例，这样他们可能会考虑其他解决问题的方案。

Answer 7

评论者：alexmiller

这个补丁只是解决了症状，而不是问题。我们真正需要的是引起问题的规范和数据值。

Answer 8

评论者：johanatan

补丁正好做到了它声称要做到的事情：为这种场景提供更好的消息。

不幸的是，我尝试从头开始构建最小化复现未成功。我明白你希望我进行更多工作，但我到目前为止所做的所有工作是免费的，我现在无法再为这个项目捐赠更多时间。

我们应该单独讨论这个补丁的优点--它与之前的代码相比是否有改进？（链接：代码的静态人工分析可以确定它确实是一个改进）。这里的“根本问题”在于 s/valid? 和 s/explain-data 不是纯的、全函数--它们可能会根据参数概率性地失败（即，当涉及高阶函数时（链接：由于规范的基本局限性，只能通过通过它传递随机数据来“验证”它））。实际上，鉴于这种限制，我想不出更好的办法来解决这个问题的（除了传播异常，这在我在原生态复现中的确发生了，但在我的最小化复现尝试中却没有）。

Answer 9

评论者：johanatan

我期待对这些理由做出反应。

Answer 10

评论者：gshayban

如果没有复现案例，恐怕这个问题不会得到进一步处理。如果存在违反不变量（例如，无效数据但缺少解释数据），请提供一个示例。例子不必是最小化的，只需要可复现。

(链接：1) https://dev.clojure.org/display/community/Creating Tickets
(链接：2) https://dev.clojure.org/display/community/Developing Patches（参见在编码之前）

Answer 11

评论者：johanatan

那么，你是说Clojure项目不接受通过人工检查发现的错误报告吗？如果是，那么你应该考虑这个问题是一个这样的案例。

另外，如果你会思考这两个相关的函数，你就可以自行“发现”这个问题。你接受和不是纯粹确定性的吗？也就是说，它们可以在两次连续运行中给出与彼此和自己不同的结果。如果你接受这一点，那么你就已经说服自己这个错误声明是有效的（我强烈建议你接受这一点，因为这是现状）。

Answer 12

评论者：gshayban

我正在尝试帮助你制定一个更好、可操作的工单。我不代表Clojure项目。我恳求你降低敌意。像“如果你会让你自己仅仅思考这两个相关的函数”这样的话语不适合这里。

我不怀疑你已经发现了问题，但是根据目前的情况，这是无法采取行动的。

Answer 13

评论者：johanatan

我认为你应该回过头去重新阅读我之前的消息。想象一下，如果是平静、直率、理所当然地说的，因为这就是它的写法/意图（而不是你选择如何解读它）。另外，这并不是新的信息——只是以前通讯的改写（似乎没有被理解）。

我真的非常不喜欢你在之前的消息中的伪善、居高临下、施舍般的语气。请在适当的地方（无论在哪里）展示你的道德姿态。在技术错误报告中没有它的位置。

Answer 14

评论者：alexmiller

关于非确定性，这是一个在CLJ-1949中被跟踪的已知问题。假设这个问题得到解决，我觉得不需要进行这种更改。然而，我不确定所有这些都应该去哪里，所以我会暂时保留这张工单，并推迟到问题更加明确的时候。

Answer 15

评论者：johanatan

啊，是的，如果CLJ-1949被修复，那么这就不会是一个问题。感谢你的（合理的）解释。