将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

有人会回应这个吗？反馈补丁/拉取请求的通常预期响应时间是多少？

Answer 3

评论由：alexmiller 提出

此处信息不足，无法对此票据采取行动。如果（s/valid? spec data）为假，则（s/explain-data spec data）不应该为nil。你看到这种情况是spec实现中存在bug的迹象，但没有更多关于spec或数据的详细信息，目前我无法做任何事情。

Answer 4

评论由：johanatan

“可操作”的部分是指提交的补丁。此代码更健壮，对受该问题影响的人更加友好。

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

Answer 5

评论由：johanatan

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

Answer 6

评论由：jafingerhut 提出

由于你是Clojure贡献者的名单之一，我已经提高了你Clojure JIRA的权限，你应该现在能够编辑票据。

我认为没有一定的“常规时间”可以回应该票据。这可能会因问题的清晰度和紧迫性而有很大差异。

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 和 s/valid? 不是纯粹决定性的吗？即，它们可能在连续运行中的相同输入下返回与彼此和自己不同的结果。如果您接受这一点，那么您已经说服自己这个错误声明的有效性（我强烈建议您接受这一点，因为这是实际情况）。

Answer 12

gshayban 的评论

我正在尝试帮你制定一个更好、可实施的工单。我并不代表'Clojure项目'发言。我恳请您降低敌对情绪。类似“如果你能让自己仅仅思考一下这两个相关的函数”之类的语言不适合这里。

我并不怀疑你揭示了一个问题，但是的现状是无法采取行动的。

Answer 13

评论由：johanatan

我认为你应该回顾并重新阅读我之前的消息。想象一下，如果它是平静、直率且客观地说出来的，因为这就是它被写成/意图的方式（而不是你选择读取的方式）。此外，这并不是新信息——只是对之前通信的重新措辞（似乎没有被理解）。

我真的不欣赏你在之前的消息中表现出的自以为是、居高临下和讨好。把道德高调留到更合适的地方（无论在哪里）吧。在技术错误报告中，这不合适。

Answer 14

评论由：alexmiller 提出

关于非确定性，这是在CLJ-1949中跟踪的已知问题。假设这已经被解决，我觉得不需要这个更改。然而，我不确定所有这些都应该去哪里，所以我会先留下这个工单，留待以后更清晰的时候再处理。

Answer 15

评论由：johanatan

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