spec 将 nil 作为第二个参数传递给 `ExceptionInfo` 构造函数...

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

这个票据（ticket）的信息不足以采取行动。如果（s/valid? spec data）是假的，那么（s/explain-data spec data）不应该是nil。你看到这一点表示在规范实现中存在一个错误，但在没有更多关于规范或数据的信息的情况下，我目前无法采取任何行动。

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

此外，如果您允许自己去思考这两个相关函数，您就可以“发现”这个错误。您接受 s/explain-data 和 s/valid? 不是纯粹的决定性函数吗？也就是说，它们可以在两次连续运行时，在相同的输入下返回与彼此和自身都不同的结果。如果您接受这一点，那么您已经说服了自己，这个错误的说法是有效的（我强烈建议您接受这一点，因为它确实是这种情况的真实反映）。

Answer 12

评论者：gshayban

我正在努力帮您制定一个更好、可执行的工单。我不代表“Clojure 项目”。我恳请您降低敌意。像“如果您允许自己去思考这两个相关函数”之类的语言不适合这里。

我并不怀疑您确实发现了问题，但按现状来看，这无法采取行动。

Answer 13

评论由：johanatan

我认为您应该回过头去重新阅读我之前的消息。想象一下，它是以平静、坦率、实际的方式说出的，因为这正是它的写作/意图所在（而不是您选择去理解的方式）。此外，这并不是新的信息——只是以前通信（看来没有被理解）的一种重新措辞。

我真的不喜欢您之前给我的消息中那种自以为是、居高临下、庇护的感觉。将道德高论留到更合适的地方去吧（无论在哪里）。在技术错误报告中找不到它的位置。

Answer 14

评论人：alexmiller

关于非决定性，这是追踪在 CLJ-1949 中的已知问题。假定这一问题得以解决，我认为不需要进行这项更改。然而，我不确定一切都去哪里了，所以我只是将此工单留开放置，稍后再做决定。

Answer 15

评论由：johanatan

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