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

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，则在31行抛出`ExceptionInfo`异常。

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

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

遗憾的是，我没有最小化测试案例，因为这代码是专有和复杂的。

或许阅读代码的作者会有更多的洞察。

以下是完整的堆栈跟踪

(链接：[clojure.lang.ExceptionInfo "ExceptionInfo.java" 31] (链接：clojure.lang.ExceptionInfo "ExceptionInfo.java" 22) (链接：clojure.core$ex_info 调用静态 "core.clj" 4739) (链接：clojure.core$ex_info 调用 "core.clj" 4739) (链接：clojure.spec.test.alpha$explain_check 调用静态 "alpha.clj" 277) (链接：clojure.spec.test.alpha$explain_check 调用 "alpha.clj" 275) (链接：clojure.spec.test.alpha$check_call 调用静态 "alpha.clj" 295) (链接：clojure.spec.test.alpha$check_call 调用 "alpha.clj" 285) (链接：clojure.spec.test.alpha$quick_check$fn__2986 调用 "alpha.clj" 308) (链接：clojure.lang.AFn 调用帮助 "AFn.java" 154) (链接：clojure.lang.AFn 调用 "AFn.java" 144) (链接：clojure.core$apply 调用静态 "core.clj" 657) (链接：clojure.core$apply 调用 "core.clj" 652) (链接：clojure.test.check.properties$apply_gen$fn__16139$fn__16140 调用 "properties.cljc" 30) (链接：clojure.test.check.properties$apply_gen$fn__16139 调用 "properties.cljc" 29) (链接：clojure.test.check.rose_tree$fmap 调用静态 "rose_tree.cljc" 77) (链接：clojure.test.check.rose_tree$fmap 调用 "rose_tree.cljc" 73) (链接：clojure.test.check.generators$fmap$fn__9199 调用 "generators.cljc" 101) (链接：clojure.test.check.generators$gen_fmap$fn__9173 调用 "generators.cljc" 57) (链接：clojure.test.check.generators$call_gen 调用静态 "generators.cljc" 41) (链接：clojure.test.check.generators$call_gen 调用 "generators.cljc" 37) (链接：clojure.test.check$quick_check 调用静态 "check.cljc" 94) (链接：clojure.test.check$quick_check doInvoke "check.cljc" 37) (链接：clojure.lang.RestFn 调用 "RestFn.java" 425) (链接：clojure.lang.AFn 调用帮助 "AFn.java" 156) (链接：clojure.lang.RestFn 调用 "RestFn.java" 132) (链接：clojure.core$apply 调用静态 "core.clj" 657) (链接：clojure.core$apply 调用 "core.clj" 652) (链接：clojure.spec.gen.alpha$quick_check 调用静态 "alpha.clj" 29) (链接：clojure.spec.gen.alpha$quick_check doInvoke "alpha.clj" 27) (链接：clojure.lang.RestFn 调用 "RestFn.java" 137) (链接：clojure.core$apply 调用静态 "core.clj" 661) (链接：clojure.core$apply 调用 "core.clj" 652) (链接：clojure.spec.test.alpha$quick_check 调用静态 "alpha.clj" 309) (链接：clojure.spec.test.alpha$quick_check 调用 "alpha.clj" 302) (链接：clojure.spec.test.alpha$check_1 调用静态 "alpha.clj" 335) (链接：clojure.spec.test.alpha$check_1 调用 "alpha.clj" 323) (链接：clojure.spec.test.alpha$check$fn__3005 调用 "alpha.clj" 411) (链接：clojure.core$pmap$fn__8105$fn__8106 调用 "core.clj" 6942) (链接：clojure.core$binding_conveyor_fn$fn__5476 调用 "core.clj" 2022) (链接：clojure.lang.AFn 调用 "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 数据)为假，则(s/explain-data spec 数据)永远不会为nil。你看到这一点是规格实现中存在错误的指示，但没有更多关于规格或数据的详细信息，我目前无能为力。

Answer 4

评论由：johanatan

"可操作"部分是指提交的补丁。此代码对受影响的人更加健壮和友好。

此工票的实际文本只是原始的副本来称呼（因为我不能重新打开或编辑原始版本）。

Answer 5

评论由：johanatan

也就是说，我能够提交此补丁的唯一方法就是创建一个副本来称呼。

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

如果没有复现案例，我担心这不会进一步发展。如果存在被破坏的常量（例如，无效数据但缺少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被解决了，那就不会有这个问题了。感谢你（合理的）解释。