向 `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 行抛出异常。

一个天真的修复可能是
(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)为false，则(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

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

Answer 8

评论由：johanatan 提供

该补丁确实按照它所说的那样做：为这种情况提供更好的消息。

遗憾的是，我尝试从头开始构建一个最小化复现实例并没有成功。我理解你希望我继续工作，但到目前为止我所做的一切都是无偿的，我目前无法将更多的时间投入到这个问题上。

我们应该讨论这个补丁的优点——它是否是优于之前代码的改进？（链接：静态人工分析代码可以确定它是改进了）。这里的“根本问题”在于，s/valid? 和 s/explain-data 不是纯粹的全函数——它们可能根据参数以概率性失败（即当涉及高阶函数时（链接：由于规范的根本限制，只能通过传递随机数据通过它来“验证”它））。事实上，考虑到这个限制，我想不出任何更好的方法来解决此问题（除了抛出异常，这在我的原始、真实世界的复现中确实发生了，但在我的最小化复现尝试中没有发生）。

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被解决了，那么这个问题就不会存在了。感谢你（合理的）解释。