在 `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 ...))))

但这样做实际上只是掩盖了问题，并未提供有用的错误信息。

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

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

以下是完整的堆栈跟踪

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

Answer 1

评论由：johanatan 发表

因此，我终于追踪到这个问题，我的被测试函数返回的函数值在某个特定输入上会抛出异常。

这个补丁有助于引导人们到达这个方向（虽然更好的办法是显示/解释潜在失败的原因，而不仅仅是含糊其辞）。

Answer 2

评论由：johanatan 发表

有人会对此做出回应吗？对于补丁/拉取请求的反馈通常需要多长时间？

Answer 3

评论由：alexmiller 发布

这里的信息不足以对此工单采取行动。如果(s/valid? spec data)为假，则(s/explain-data spec data)决不应为nil。你看到的事实表明spec实现中存在一个bug，但没有更多关于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不是纯函数，它们可能会根据输入参数以概率性的方式失败（即，当涉及到高阶函数时（链接：由于规范的基本限制，只能通过传递随机数据来“验证”））。事实上，鉴于这种限制，我无法想象有比这更好的解决这个问题的方式（除了抛出异常，这在我的原始的真实世界重现中确实是吞没的，但在我的最小化尝试中并没有）。

Answer 9

评论由：johanatan 发表

我期待看到对该推理的回应。

Answer 10

评论者：gshayban

没有重现案例，我恐怕这个问题无法向前推进。如果有某种不变性被破坏（例如，无效数据但缺少explain-data），请提供一个例子。它不必是最小化的，只需要是可重现的。

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

Answer 11

评论由：johanatan 发表

那么，您是说Clojure项目不接受通过人工检验发现的错误报告吗？因为如果这样做，那么您应该考虑这个错误报告就是一个例子。

此外，如果您愿意仅仅思考一下这两个问题函数，您就能“发现”这个bug。您是否接受s/explain-data和s/valid?不是纯粹确定性的？例如，它们可能在连续两次运行中给出与彼此和相关输入不同的结果。如果接受这一点，那么您已经相信了这一bug声明的有效性（并强烈敦促您接受这一点，因为这是现实中的情况）。

Answer 12

评论者：gshayban

我在尝试帮助你制定一个更好、更具操作性的工单。我不是代表'Clojure项目'讲话。我请求你降低对立情绪。像“如果你允许自己仅仅考虑这两个相关函数”这样的语言不适合在这里。

我不怀疑你已经发现了一个问题，但就目前情况来看，这无法采取行动。

Answer 13

评论由：johanatan 发表

我认为你应该回过头去重新阅读我之前的消息。想象它是以平静、直白和客观的方式说的，因为这就是它的写法/意图（而不是你选择去解读的方式）。此外，这不是新信息——只是对先前通信的改写（看起来并没有被理解）。

我真的不 appreciate 你之前给我的消息中那种虔诚的、俯视的、庇护的态度。把道德高调的东西留给更合适的地方（无论那个地方是什么）。这在技术错误报告中没有位置。

Answer 14

评论由：alexmiller 发布

关于非确定性，这是在CLJ-1949中被跟踪的一个已知问题。假设这个问题得到了解决，我看不出进行这个改变的需要。然而，我不确定所有这些会去哪里，所以我只是保持这个工单开放，并在它变得更明朗时再进行推迟。

Answer 15

评论由：johanatan 发表

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