向 `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，则在 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 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。您所看到的这一现象表明规范实现存在错误，但如果没有更多关于规范或数据的信息，我目前无法做任何事情。

Answer 4

评论由：johanatan 发表

"可采取行动"的部分是指提交的补丁。这段代码对受问题影响的人来说更为健壮和友好。

该票的实际文本仅仅是原始票的克隆（因为我不能重新打开或编辑原始票）。

Answer 5

评论由：johanatan 发表

也就是说，唯一能够提交此补丁的方式是创建一个克隆。

Answer 6

评论者：jafingerhut

Jonathan，由于你是 Clojure 贡献者的名单之一，我提升了你在 Clojure JIRA 上的权限，因此你现在应该能够编辑票据。

我认为没有“通常的时间”来响应票据。它可以根据问题的清晰度和被视为的重要性而变化。

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

Answer 7

评论者：alexmiller

该补丁解决的是症状，而不是问题。我们真正需要导致问题的规范和数据值。

Answer 8

评论由：johanatan 发表

该补丁确实做到了它所说的内容：为这种情况提供更好的消息。

遗憾的是，我尝试从头开始构造一个最小重复案例并不成功。我明白您希望我做更多的工作，但我到目前为止所做的一切都是无偿的，在这个时候我无法再为这项事业捐献更多的时间。

我们应该单独讨论这个补丁的优点---它与之前的代码相比是否有改进？（链接：静态代码分析可以确定它确实有改进）。这里的“根本问题”在于 s/valid? 和 不是纯净的完全函数——它们可能会根据参数以概率失败（例如，当涉及到高阶函数时（链接：由于规范的基本限制，只能通过通过随机数据通过它来“验证”))。事实上，鉴于这个限制，我无法想象有更好的解决办法来解决这个问题（除了上抛异常，这确实在我最初真实世界的复现中发生，但在我的最小化复现中却没有）。

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 得以修复，那么这个问题就不会出现了。感谢您的（合理的）解释。