评论者：cemerick
SS 关于这一点，这种方法对 Maven 不会造成任何问题。此外，构建可以很容易地配置为始终生成两个 JAR 文件，一个是“正常”的，一个是“调试”的。
我建议，虽然 {{clojure.debug}} 可能会有广泛的影响，但还应该有额外的属性可供使用，以提供对未来可能出现的每个“调试”相关参数化更细粒度的控制。
我想提出几个可能相关的担忧（在思考上面的断言后），其中一些或全部可能只是我对自己在各个领域理解不足的结果。
观察 {{core.clj}} 中 {{assert}} 的使用情况（据我所知只有两个地方：验证 {{derive}} 的参数和维护 {{fn}} 的前、后条件），似乎使其默认为 false 是不明智的。也就是说，非 {{Named}} 值将能够进入层次结构，而且前、后条件将简单地被忽略。
根据我的理解，断言（在这里指JVM构造，Clojure重用它于{{AssertionError}}）不应用于验证公共API函数的参数，或用于验证函数正常操作的任何方面（例如，（链接：http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage 文本：“不胜任使用断言”))). 这意味着{{derive}}在必要时应该抛出{{IllegalArgumentException}}，而fn前后的条件可能应该抛出{{IllegalStateException}}——或者无论如何，应该通过{{assert}}抛出除了{{AssertionError}}之外的某种异常。这将非常好地与大部分使用{{assert-args}}而不是{{assert}}的核心函数相匹配，前者会抛出{{IllegalArgumentException}}而不是{{AssertionError}}。
这使我想到一个问题：{{assert}}（和* ）是不是 Clojure 构造，或者是一个准互操作形式？
如果是前者，那么它的大致语义可以随心所欲，但似乎不应该抛出{{AssertionError}}。
如果是后者，那么在 JVM 上{{AssertionError}}是适当的，但我们需要注意断言能够在运行时启用和禁用（无需在不同版本的 Clojure 之间来回切换），理想情况下使用主机定义的开关（例如 {{-ea}} 和它的朋友），可能不应该有像* 这样的事物。我不知道这一点现在是否可行或实用（我猜想这需要不平凡的编译器更改）。
希望上述内容目前并不会成为过去式。提前感谢您的耐心。；-)
