格式错误的预/后条件被默默通过

Question

之前


user=> ((fn [x] {:pre (pos? x)} x) -5) ; ouch!
-5
user=> ((fn [x] {:pre [(pos? x)]} x) -5) ; meant this
AssertionError 断言失败: (pos? x)  user/eval4075/fn--4076 (form-init5464179453862723045.clj:1)


之后


user=> ((fn [x] {:pre (pos? x)} x) -5)
CompilerException 编译异常 java.lang.IllegalArgumentException: 预和后条件应该是向量，编译:(NO_SOURCE_PATH:1:2)
user=> ((fn [x] {:pre [(pos? x)]} x) -5)
AssertionError 断言失败: (pos? x)  user/eval2/fn--3 (NO_SOURCE_FILE:2)
user=> ((fn [x] {:post (pos? x)} x) -5)
CompilerException 编译异常 java.lang.IllegalArgumentException: 预和后条件应该是向量，编译:(NO_SOURCE_PATH:3:2)
user=> ((fn [x] {:post [(pos? x)]} x) -5)
AssertionError 断言失败: (pos? x)  user/eval7/fn--8 (NO_SOURCE_FILE:4)


*补丁:* CLJ-1473_v03.patch
*审核人:* Alex Miller

Answer 1

评论者：alexmiller

在错误中包含格式错误的条件（或许通过 ex-info 那样）并添加测试将会很方便。

Answer 2

评论者：bbloom

新补丁包含测试。不幸的是，由于引导问题，不能直接调用 ex-info。而是直接调用 ExceptionInfo 构造函数。

Answer 3

评论人：alexmiller

报告中存在错误：{:post pre} 应该是 {:post post}。

测试应该被改进，因为它本可以捕捉到这一点。

Answer 4

评论者：bbloom

很好，捕捉到了预处理/后置复制粘贴错误。但是并未增强测试，因为这会造成创建一个对ex-info友好的变体 fails-with-cause

Answer 5

评论人：richhickey

:pre 和 :post 不需要向量，只需是集合

Answer 6

评论人：jafingerhut

Eastwood 0.2.2 版本于2015年11月15日发布，将提醒几种不正确的预处理和后置条件。请参阅https://github.com/jonase/eastwood#wrong-pre-post

Eastwood 的文档可能目前有误导性，因为它指出 :pre 和 :post 应该是向量，这与 Rich 2015年10月9日的评论相矛盾。欢迎对 Eastwood 文档进行更正。我认为 Rich 的意图是 :pre 和 :post 可以是向量、列表或集合？那里是否可以适用映射？

Answer 7

评论人：marco.m

有新消息吗？

Answer 8

评论人：alexmiller

Rich 的反馈在上述内容中尚未得到回应。我尝试了一下更新，但将约束放宽为“表达式集合”是相当有趣的。一旦这样做，那么这里票证的第一示例 {:pre (pos? x)} 实际上并不是无效的，它实际上是两个东西的集合：pos? 和 x。pos? 计算为真（它是一个函数）并且 x 在任何数上计算为真。

我不确定在那方面的前进之路是什么。将传入参数作为先决条件进行引用是完全有效甚至是潜在有用的，这只是一个符号


((fn [v] {:pre [v]} v) nil)  ;; 先决条件应该失败
((fn [v] {:pre (v)} v) nil)  ;; 同样有效


也许你可以检查pre或post的元素是否是列表（表达式）或符号参数绑定？其他任何东西都是空洞的真理，很可能是一个错误。不确定。

Answer 9

_评论者：jafingerhut_

Eastwood仍然会警告如下代码


(defn foo [x]
  {:pre [pos? x]}
  (inc x))


以下是示例输出

src/filename.clj:5:22: wrong-pre-post: 找到的先决条件可能是始终逻辑为真或始终逻辑为假的。 应该改为函数调用？ pos?

即使Rich发表了评论，它仍然会警告：pre或:post的值不是矢量时，因此在某种程度上过于严格，但这可能不是过于严格到令人难以接受。

Answer 10

评论者：martinklepsch

只想指出这个PR（https://github.com/pedestal/pedestal/pull/544）是如何影响生产Clojure代码的。

由于不正确的先决条件/后置条件被静默接受，API本质上与库作者的意图不同。人们开始依赖于它，修复损坏的先决条件在很大程度上导致了破坏性变化。

Answer 11

参考资料： https://clojure.atlassian.net/browse/CLJ-1473（由bbloom汇报 ）