异常与断言?
可能的重复:
通过断言或异常进行合约测试设计?
在决定使用异常而不是断言时是否有可遵循的经验法则(反之亦然)。 现在,我仅在我认为用户端运行时会发生的情况(如套接字或文件错误)时抛出。 几乎所有其他事情我都使用断言。
另外,如果我要抛出一个断言,那么抛出一个好的标准对象是什么? 如果我没记错的话,有 std::logic_error
,但这不是一个好的抛出对象吗? 对于丢失的文件或意外的输入(例如来自命令行而不是前端应用程序),我会抛出什么?
Possible Duplicate:
design by contract tests by assert or by exception?
Is there a rule of thumb to follow when deciding to use exceptions instead of asserts (or vice versa). Right now I do only throw if it's something I think will happen during runtime on the user side (like a socket or file error). Almost everything else I use asserts.
Also, if I were to throw an assert, what is a nice standard object to throw? If I recall correctly there is std::logic_error
, but is that not a good object to throw? What would I throw for a missing file or unexpected input (such as from the command line instead of a frontend app)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我的经验法则:
异常用于运行时错误情况(IO 错误、内存不足、无法获取数据库连接等)。
断言用于编码错误(此方法不接受空值,开发人员无论如何都传递了一个)。
对于具有公共类的库,在公共方法上抛出异常(因为这样做是有意义的)。 断言用于发现你的错误,而不是他们的错误。
编辑:由于空值示例,这可能不完全清楚。 我的观点是,对于永远不应该发生的情况、永远不应该进入生产代码的情况,使用断言(正如其他人指出的那样)。 在单元测试或 QA 测试期间,这些条件绝对必须失败。
My rule of thumb:
Exceptions are used for run-time error conditions (IO errors, out of memory, can't get a database connection, etc.).
Assertions are used for coding errors (this method doesn't accept nulls, and the developer passed one anyway).
For libraries with public classes, throw exceptions on the public methods (because it makes sense to do so). Assertions are used to catch YOUR mistakes, not theirs.
EDIT: This may not be entirely clear, due to the null value example. My point is that you use assertions (as others have pointed out) for conditions that should NEVER happen, for conditions that should NEVER make it into production code. These conditions absolutely must fail during unit testing or QA testing.
断言你知道不会发生的事情(即如果它发生了,那是你无能的错)。
引发程序的常规控制流未处理的异常情况。
Assert the stuff that you know cannot happen (i.e. if it happens, it's your fault for being incompetent).
Raise exceptional situations which are not treated by the regular control flow of the program.
我将断言用于那些不应该发生但却发生的事情。 当这种情况发生时,开发人员需要重新审视错误的假设。
我对其他一切都使用例外。
在可重用代码中,我更喜欢异常,因为它使调用者可以选择处理或不处理问题。 只需尝试捕获并处理断言即可!
I use asserts for things that should never happen, yet do. The sort of thing that when it happens, the developer needs to revisit incorrect assumptions.
I use exceptions for everything else.
In reusable code, I prefer an exception because it gives the caller a choice of handling or not handling the problem. Just try catching and handling an assert!
您可以在例外情况下使用例外。 例如内存不足或网络故障。
您可以使用断言来确定是否满足某个前提条件。 例如,指针不为 NULL 或整数在某个范围内。
You use exceptions for exceptional situations. For example an out of memory situation or a network failure.
You use assert to ascertain that a cetain precondition is met. For example a pointer is not NULL or an integer is within a certain range.
断言是验证程序是否处于可能状态的一种手段。 如果一个函数在它应该只返回正整数时返回 -1,并且您有一个断言来验证这一点,那么您的程序应该停止,因为它会使您的程序处于危险状态。
Assert is a means to verify that the program is in a possible state. If a function returns -1 when it should only return positive integers, and you have an assert that verifies that, your program should stop because it puts your program in a dangerous state.
作为一般规则,我从以下位置抛出异常:
我仅在内部使用断言来捕获实现错误。
As a general rule, I throw exceptions from:
where I use asserts only internally to catch implementation mistakes.