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

"可操作的"部分是提交的补丁。这个代码更健壮，对受此问题困扰的人更友好。

实际的票并不是别处克隆的（因为不能重新打开或修改原始的）。

Answer 5

评论者：johanatan

即，唯一能提交这个补丁的方法是创建一个克隆。

Answer 6

评论者：jafingerhut

约翰逊，因为你名列 Clojure 贡献者名单，我已经提高了你在 Clojure JIRA 的权限，你现在应该能够编辑工单了。

我认为没有固定的回复时间。根据问题的清晰度和紧迫程度，回复时间可能会有很大的差异。

亚历克斯可能会欣赏如果描述包括一个可以用来复现问题的示例。通常，通过看到问题，他们可能会考虑其他解决问题的方案。

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项目不接受通过手动人工检查发现的错误报告吗？如果它接受，那么你应该认为这个错误是一个这样的情况。

此外，如果您愿意仅仅思考这两个问题中的函数，您就可以“发现”这个错误。您接受s/explain-data和s/valid?不是纯粹的确定性函数吗？即，在两次连续运行中，它们可以给出与彼此和自身都不同的结果。如果您接受这一点，那么您已经使你自己相信了这个错误的正确性（我强烈建议您接受这一点，因为这确实是事情的真实情况）。

Answer 12

评论者：gshayban

我正在尝试帮助您制定一个更好、可执行的工单。我不代表Clojure项目发言。我敦促您降低敌意。像“如果您愿意只思考这两个被讨论的函数”这样的语言不适合这里。

我毫不怀疑您已经发现了一个问题，但就现状而言，这是不可执行的。

Answer 13

评论者：johanatan

我认为你应该重新阅读我之前的消息。想象它是以平静、坦率和客观的方式说的，因为这正是它被写成的/本来的含义（而不是你选择如何阅读它）。此外，这不是新信息——只是对先前通信（似乎没有理解）的改写。

而且我真的不赞赏你之前给我发消息时所表现出的自以为是、居高临下和轻蔑的态度。请把道德的夸张保留在更合适的地方（无论在哪里）。这不适合技术错误报告。

Answer 14

评论者：alexmiller

关于非确定性，那是CLJ-1949中的一个已知问题正在跟踪。假设这个问题得到了解决，我看不出进行这种改变的需要。然而，我不确定所有这些会去哪里，所以我将把这个问题单留开放，等变得更清楚时再议。

Answer 15

评论者：johanatan

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