将 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 ...))))

尽管这实际上只是在掩盖问题，并没有为失败者提供可行动的信息。

遗憾的是，我没有最小测试用例，因为这涉及专有且复杂的代码。

也许作者可以阅读代码后获得更多信息。

这是完整的堆栈跟踪

(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.beta()()$quick_check invokeStatic "alpha.clj" 29) (link: clojure.spec.gen.beta()()$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数据）为假，则（s/explain-data spec数据）永远不应该为nil。你看到的是spec实现中的bug的指标，但没有更多关于spec或数据的信息，我目前无法做任何事情。

Answer 4

评论者：johanatan

“可行动”的部分是提交的补丁。这段代码对遭受该问题的用户更加坚韧和友好。

这个工单的全文仅仅是原始工单的一个克隆（因为我不能重新打开或编辑原始工单）。

Answer 5

评论者：johanatan

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

Answer 6

评论由：jafingerhut 发布

Jonathan，你被列入Clojure贡献者名单，我已经提升你在Clojure JIRA上的权限，所以你现在应该可以编辑工单了。

我认为并没有一个“通常的回复时间”来回答工单。这可能因问题的清晰程度和认为的重要程度而有所不同。

Alex可能会希望描述中包含一个可以用来复现问题的示例。通常，在看到问题后，他们可能会考虑其他解决问题的方法。

Answer 7

评论者：alexmiller

这个补丁针对的是症状，而不是问题。我们真的需要导致问题的spec和数据值。

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被修复，那么这就不会成为问题。感谢你的（合理的）解释。