在`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 data)为false，则(s/explain-data spec data)永远不应该为nil。你看到这一点是表明spec实现中存在错误的信号，但如果没有更多关于spec或数据的信息，我目前无法做什么。

Answer 4

评论者：johanatan

"可操作"的部分是提交的补丁。这段代码对受问题困扰者更为健壮和友好。

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

Answer 5

评论者：johanatan

也就是说，我提交这个补丁的唯一方法是创建一个CLONE。

Answer 6

评论由：jafingerhut 发布

Jonathan，鉴于你是 Clojure 贡献者名单上的一员，我已经提高了你在 Clojure JIRA 上的权限，所以你应该现在可以编辑票据了。

我认为没有常规的响应时间。它可能因问题的清晰度和感知到的紧急性而以数量级变化。

Alex 可能会感激，如果描述中包含了一个可以用来重现问题的示例。通常，通过看到问题，他们可能会考虑其他解决方案。

Answer 7

评论者：alexmiller

修复方案只是解决了症状，并没有解决问题。我们真的需要引起问题的 spec 和数据值。

Answer 8

评论者：johanatan

修复方案确实做到了它所宣称的事情：为这种情况提供更好的消息。

不幸的是，我从头开始构造最小重现版本的努力并不成功。我理解您希望我进行更多工作，但到目前为止我所有的努力都是无偿的，并且我现在无法再为此事业捐出更多时间。

我们应该单独讨论这个修复方案的优点——它是否优于之前的代码？（链接：代码的静态人工分析可以确定它确实是一个改进）。这里的“根本问题”是 s/valid?和 s/explain-data 不是纯净的、完全的函数——它们可能会根据参数以概率失败（即，当涉及高阶函数时（链接：由于 spec 的基本限制，它只能通过通过它传递随机数据来“验证”)))。事实上，鉴于这种限制，我想不出任何更好的方式来解决这个问题（除了抛出异常，这在我的原始、现实世界的重建中肯定被吞没了，但在我的最小重建尝试中却没有）。

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项目不接受通过人工检查发现的bug报告？因为如果它接受这样的报告，那么您应该考虑这个bug是这种情况下的一种。

此外，如果您愿意仅仅是思考一下这两个争议函数，您就可以自己“发现”这个bug。您接受s/explain-data和s/valid?不是纯粹确定性的吗？也就是说，在两次连续运行中，它们可以给出与彼此和自身都不同的结果。如果您接受这一点，那么您已经说服了自己这个bug声明的有效性（并且我强烈敦促您接受这一点，因为这是情况的现实）。

Answer 12

评论者：gshayban

我正在尝试帮助您制定一个更好、可操作的票证。我并不代表“Clojure项目”。我恳请您降低敌意。如同“如果您愿意仅仅是思考一下这两个争议函数”这样的措辞在这里是不合适的。

我并不怀疑您已经发现了问题，但正如目前这样，这是无法采取行动的。

Answer 13

评论者：johanatan

我认为您应该重新阅读我之前的消息。想象一下，它是以平静、坦率和实际的方式说出的，因为这就是它的写作/意图（而不是您自己所选择的那样）。此外，这并非新信息——仅仅是对先前通信（似乎没有被理解）的改写。

我在您的上一条信息中真的很不喜欢那种自以为是、屈尊降贵、轻视人的语气。把那一套道德高调留给更合适的地方吧（无论在哪里）。在一个技术bug报告中，它没有位置。

Answer 14

评论者：alexmiller

关于非确定性，这是一个在CLJ-1949中跟踪的已知问题。假设这个问题得到了解决，我看不到进行此更改的必要性。然而，我不确定所有这些会去哪里，所以我只是将这个工单保留开放状态，并推迟到以后那变得更清晰时。

Answer 15

评论者：johanatan

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