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

尽管这实际上只是在掩盖问题，而没有为失败者提供任何可操作的信息。

遗憾的是，由于这是专有代码（且复杂），我没有任何最小测试用例。

也许从阅读代码的作者那里会有更多的洞察。

以下是完整的堆栈跟踪

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

Jonathan，由于你是在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 提出

我认为你应该回过头去重新阅读我之前的消息。想象一下，如果是平静、 straightforward 和实事求是地说出来，因为这些就是它被写成/目的是这样的（而不是你选择如何阅读它）。此外，这也不是新信息——只是对之前的通信（似乎没有被发现）的重写。

我真的非常不欣赏你之前给我的消息中的那副神圣、居高临下、居高临下的态度。将道德宏伟的做法留到更合适的地方去吧（无论在哪里）。在技术错误报告中它没有位置。

Answer 14

评论者：alexmiller

关于非确定性，这是在 CLJ-1949 中跟踪的已知问题。假设这已经得到解决，我看不出这个改变的需要。然而，我不确定这些会放到哪里，所以我只是暂时留下这个工单，稍后再说。

Answer 15

评论由：johanatan 提出

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