将空值传递给`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`返回空值，`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。你看到这一情况表明spec实现中存在一个bug，但没有关于spec或数据的更多信息，我目前什么也无法做。

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不是纯函数，它们可以根据参数（即在涉及高阶函数时）概率性地失败——（链接：由于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 和 s/valid? 不是纯确定性的？也就是说，在连续两次运行中，它们可以给出完全不同的结果，即使输入完全相同。如果你接受这一点，那么你就已经说服了自己这个虫子报告的有效性（我强烈要求你接受，因为这确实是这种情况的现实）。

Answer 12

评论者：gshayban

我正在尝试帮助你制定一份更好、更有行动性的票据。我并不是代表‘Clojure项目’讲话。我恳求你降低敌意。像“如果你会给自己的这两个函数一个思考”这样的语言在这里不合适。

我不怀疑你发现了一个问题，但按照目前的情况，这是不可执行的。

Answer 13

由johanatan发表评论

我认为你应该回去重新阅读我之前的信息。想象一下，它被平静、直言不讳地说出，因为这就是它的写作意图（而不是你选择的读法）。此外，这并不是新信息——只是对先前通讯（似乎并未理解）的一种改写。

我真的非常不欣赏你在给我之前的消息中的自以为是的、傲慢的、居高临下的态度。请把这种道德上的高调留到更合适的地方（不论在哪里）。在技术错误报告中它没有任何位置。

Answer 14

由alexmiller发表评论

关于不确定性，这是CLJ-1949跟踪的已知问题。假设这个问题得到了解决，我认为没有必要进行这个更改。但是，我不确定所有的细节会如何发展，所以我只是会把这个问题单保持开放状态，并在变得更为清晰时再进行后续处理。

Answer 15

由johanatan发表评论

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