将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发布

有人要回应这个问题吗？大家对补丁/ pull 请求的反馈通常期望多长时间？

Answer 3

评论由：alexmiller添加。

这里的信息不足以处理这个工单。如果(s/valid? spec数据)为假，则(s/explain-data spec数据)应该永远不应该是nil。你看到这个现象是spec实现中存在bug的迹象，但没有更多关于spec或数据的信息，我目前做不了什么。

Answer 4

评论由：johanatan发布

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

这个工单的实际文本只是原始工单的CLONE（因为我无法重新打开或编辑原始工单）。

Answer 5

评论由：johanatan发布

也就是说，我能提交这个补丁的唯一方法就是创建一个CLONE。

Answer 6

评论由：jafingerhut添加。

Jonathan，由于你是Clojure贡献者名单上的一员，我已经提升了你在Clojure JIRA上的权限，现在你应该可以编辑工单了。

我认为没有一种“正常时间”来进行工单回复。这个时间可能会根据问题的清晰度和 perceived criticality（重要性）而有很大变化。

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和不是纯粹确定性的事实吗？即，它们可以在两次连续运行中给出与自己和对方都不同的结果，给出完全相同的输入。如果您接受这一点，那么您已经说服了自己关于这个错误断言的有效性（我强烈敦促您接受这一点，因为这是实际情况）。

Answer 12

评论者：gshayban

我正在尝试帮助您制定一个更好、可操作的问题单。我并不代表'Clojure项目'发言。我恳请您降低敌意。诸如“如果你会允许自己仅仅思考一下所讨论的两个函数”这样的语言并不属于这里。

我并不怀疑您已经发现了问题，但就目前来看，这是无法采取行动的。

Answer 13

评论由：johanatan发布

我认为你应该回过头去重新阅读我之前的消息。设想它是平静、简单和实事求是地所说的，因为它是这样写的/是这样打算的（而不是你选择如何去理解它）。此外，这并不是新的信息——只是对之前交流内容的一种重新措辞（这些内容似乎并没有被理解）。

我真的非常不喜欢你在给我的前一条消息中表现出来的伪善、轻蔑和居高临下。把道德高调放到更合适的地方（无论在哪里）去吧。它和技术缺陷报告不相符。

Answer 14

评论由：alexmiller添加。

关于非确定性，这是在 CLJ-1949 中跟踪的一个已知问题。假设这得到了解决，我认为没有必要进行此更改。然而，我不确定所有这些都将去哪里，所以我只是让这个工单保持开放，并推迟到以后情况变得更加清晰时再进行处理。

Answer 15

评论由：johanatan发布

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