在 `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。你看到这一点是表明规格实现中存在一个错误的迹象，但没有更多关于规格或数据的信息，我目前无能为力。

Answer 4

评论由：johanatan发表

“可操作”的部分是提交的补丁。这个代码对问题患者更加健壮和友好。

实际上这个工单的内容只是原始工单的CLONE（因为我不能重新打开或编辑原始工单）。

Answer 5

评论由：johanatan发表

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

Answer 6

评论由：jafingerhut 提供

Jonathan，既然你名在Clojure贡献者名单上，我为Clojure JIRA增加了你的权限，你现在应该能够编辑票据了。

我认为没有“通常的响应时间”，这可能会因问题的清晰度和感知到的紧迫性而有很大的不同。

Alex可能希望描述中包含一个可以评估以重现问题的示例。通常，通过看到问题，他们可能会考虑其他解决问题的方法。

Answer 7

评论由：alexmiller发表

该补丁针对的是症状，而不是问题。我们确实需要导致问题的特性和数据值。

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和不是纯确定性的吗？即在两次连续运行中，给定相同的输入，它们可以返回不同结果。如果你接受这一点，那么你就已经证明了错误声明的有效性（我强烈建议你接受，因为这是实际情况）。

Answer 12

评论由：gshayban

我正在试图帮助你制定一个更好、可操作的工单。我并不代表'Clojure项目'。我恳求你缓和对抗性。像“如果你会允许自己仅仅思考一下这两个疑问中的函数”这样的语言在这里是不恰当的。

我并不怀疑你已经发现了一个问题，但就现状来看，这是无法执行的。

Answer 13

评论由：johanatan发表

我认为你应该回过头去重新阅读我之前的消息。想象它是平静、简单、直截了当地说出来的，因为这正是它所被写的（而不是你选择的阅读方式）。此外，这不是新信息——只是对先前通信（看起来没有被理解）的重述。

我真的不欣赏你在之前的短信中对我的那种自以为是、居高临下、施舍的态度。将这种道德上的自诩放到更合适的地方去吧（不管在哪里）。在技术缺陷报告中不适宜这样做。

Answer 14

评论由：alexmiller发表

关于非确定性，这是一个在CLJ-1949中跟踪的已知问题。假设这个问题已经解决，我认为不需要进行这项更改。然而，我不确定所有这些问题会如何，因此我打算保留这个工单，稍后再解决这个问题。

Answer 15

评论由：johanatan发表

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