Java中的断言关键字 [英] Assert keyword in Java

查看:27
本文介绍了Java中的断言关键字的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你使用 assert 关键字还是抛出一些验证运行时异常?它给你带来什么好处,或者你为什么认为它不值得使用?

Do you use the assert keyword or throw some validation runtime exception? What benefits does it give to you or why do you think it's not worth it to use?

推荐答案

Assert 会抛出运行时错误 (AssertionError) 如果其条件为假.断言为您提供了一种简化的方式来记录、检查和强制执行代码的正确性标准.好处是用于定义和操作这些正确性条件的语言级挂钩.如果您希望启用或禁用它们(关于这是否是一个好主意存在争论),您可以从 JVM 命令行执行此操作.下面的一些评论者指出,除非在调试模式下运行,否则默认情况下断言是禁用的;我的做法是始终在我的包装脚本中添加-ea"(启用断言).即使在对性能敏感的代码中,对我来说,权衡也会有利于我从断言中获得的安全性/正确性信心.Oracle 的断言AssertionError 的 API 描述

Assert will throw a runtime error (AssertionError) if its condition is false. Asserts give you a streamlined way of documenting, checking, and enforcing correctness criteria for your code. The benefits are a language-level hook for defining and manipulating these correctness conditions. To the extent that you wish to enable or disable them (there are arguments about whether or not this is a good idea) you can do so from the JVM command-line. Some commenters below note that assertions are disabled by default unless running in debug mode; my practice is to add "-ea" (enable assertions) in my wrapper scripts at all times. Even in performance sensitive code, for me the tradeoff weighs in favor of the security/correctness confidence I get from assertions. Assertions at Oracle and API Description for AssertionError

请注意可能超出您控制范围的预期或意外失败(异常)与断言失败之间的区别——断言失败记录了程序员的假设,并表明程序不正确,而不是意外的外部条件或预期的异常情况.如果发生断言失败,解释是程序员误解或错误地表达了程序,而不是其他错误或失败的来源.

Note the distinction between expected or unexpected failures (exceptions), which may be outside your control, and assertion failures -- assertion failures document programmer assumptions, and indicate an incorrect program rather than an unexpected external condition or expected exceptional condition. If an assertion failure occurs, the interpretation is that the programmer has misunderstood or incorrectly expressed the program, rather than other sources of error or failure.

在实践中,我用它来记录我所做的明显或不明显的假设以及我在生成(特别是私有/内部)代码时想要强制执行的不变量,让我自己和其他人清楚为什么做出这些假设,它们是在哪里制造的,以及它们是否经过验证.比具有相同效果的评论要好得多.这是朝着合同设计迈出的(小)一步.

In practice, I use it to document obvious or non-obvious assumptions I make and invariants which I want to enforce as I produce (particularly private/internal) code, making it clear to myself and others why these assumptions are made, where they are made, and whether or not they are validated. Much better than comments to the same effect. This is a (small) step toward Design by Contract.

Effective Java item #38检查参数的有效性"(Google 图书Amazon.com) 提供了有关参数检查和适当使用断言之间区别的有用介绍.

Effective Java item #38 "Check Parameters for Validity" (Google Books, Amazon.com) provides a useful presentation of the distinction between parameter checking and appropriate use of assertions.

与 SO 相关:(在 netbeans 中启用断言),(断言与异常), (近乎重复,求例子), (严重命名,但内容非常相似)

Related on SO: (Enabling assertions in netbeans), (Assertions vs. Exceptions), (Near duplicate, asking for examples), (Badly named, but very similar content)

这篇关于Java中的断言关键字的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆