将 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，则在行 31 上 `ExceptionInfo` 会抛出异常。

一个简单的修复方法可能是
(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数据)不为真，则(s/explain-data spec数据)永远不该为nil。你看到这个现象是规格实现中存在错误的指示，但没有更多关于规格或数据的信息，我现在无法采取任何行动。

Answer 4

评论由: johanatan 留言

"可采取行动"的部分是提交的补丁。这段代码对这个问题的影响者更加健壮和友好。

此处票据的实际情况只是原始票据的一个CLONE（因为我无法重新打开或编辑原始票据）。

Answer 5

评论由: johanatan 留言

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

Answer 6

由 jafingerhut 发表的评论：

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

我认为没有固定的"响应时间"标准。这可以因问题的清晰度和严重性而有很大差异。

Alex会感激如果描述中包含一个可以用来重现问题的示例。通常，通过看到问题，他们可能会考虑其他解决问题的方法。

Answer 7

由 alexmiller 发表的评论：

这个补丁只是解决了症状，而不是问题。我们真正需要的是导致问题出现的规格和数据值。

Answer 8

评论由: johanatan 留言

这个补丁确实做了它声明的：为这种情况提供了更好的信息。

遗憾的是，我尝试从头开始构建最小复现版本并不成功。我知道你可能希望我继续工作，但我到目前为止所做的一切都是免费的，我目前不能为这个任务额外捐赠更多的时间。

我们应该讨论这个补丁的优缺点——它是否比以前的代码有所改进？（链接：Code的静态人工分析可以确定它事实上有所改进）。这里的根本“问题”是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 留言

我认为您应该重新阅读我之前的信息。想象一下，如果它是平静、坦诚且直率的，因为这正是我写下来想要表达的意思（而不是您选择阅读的方式）。此外，这并不是新信息——这只是对以前的通信（似乎没有被理解）的重新措辞。

我真的不喜欢您之前给我的信息中的那些 sanctimonious、condescending、patronizing。将道德的夸耀留给更合适的地方（无论在哪里）。它不适用于技术错误报告。

Answer 14

由 alexmiller 发表的评论：

关于非确定性，这是CLJ-1949中追踪的已知问题。假设这得到了解决，我认为没有必要进行这项更改。然而，我不确定所有这些该放在哪里，所以我只是会留下这个问题单，并推迟到更清楚的时候再处理。

Answer 15

评论由: johanatan 留言

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