使用assert.h [英] Use of assert.h

问题描述

一般来说，在生产中使用断言是否被认为是不好的做法

代码？


如何写一个与断言相同的宏但是继续

无论NDEBUG的状态如何工作？


我可以看到通常使用它的风格很差

遇到了错误，但是真正特殊的错误怎么会很少见到？$ div <= div> 解决方案

Rob Thorpe写道：

一般来说，在生产代码中使用断言是否被认为是不好的做法？

如何写一个与断言相同的宏但继续
无论NDEBUG的状态如何工作？

我可以看到，将它用于常见的错误是不好的风格，但真正的例外错误呢？
很少遇到过？

答案是，这取决于。


你必须考虑你的具体应用什么是最好的。

可能性包括：


1）使用适当的消息中止程序。

这可以防止给出错误的结果，因此在没有答案优于错误答案的情况下（或者破坏数据库这可能是最好的事情。


2）向调用函数返回错误状态。

如果调用函数没有处理错误，这可能导致

不正确的结果或崩溃。


3）重新启动系统（最有可能是嵌入式

系统上的选项。


4）如果
$，尝试恢复情况并重新回到1,2或3 b $ b校正似乎不起作用。


对于某些项目，如录像机，选项4可以回到3

可能是最好的解决方案。对于我正在使用选项1的一个应用程序

最好用于很多错误（防止数据被破坏以及所有

修复数据所需的工作）但是选项4回到1是

解决其他类型问题的最佳解决方案。

-

Flash Gordon

生活在有趣的时代。

虽然我的电子邮件地址是垃圾邮件，但它是真实的，我读了它。

2005年3月23日03： 15:46 - 0800，Rob Thorpe

< ro *********** @ antenova.com>写道：

一般来说，在生产代码中使用断言是否被认为是不好的做法？


我不认为有任何''一般''意见，它主要是你的b / b
雇主或顾客的想法。如果你的意思是将它们保留在代码中，并使用

NDEBUG定义，以便它们不执行任何操作。我没有看到任何问题在那里留下

。

怎么样写一个与断言相同的宏但是继续工作无论如何NDEBUG的状态？


如果它是交互式代码（我的意思是用户启动了

应用程序并且可以看到错误消息）那么我就不会认为

默认的C断言机制通常是合适的。例如，如果我使用一个单词

处理器，我不希望它在命令行中使用一些源代码退出

代码和/或核心转储，

捕获错误并向用户显示有意义的消息会更好（并且

希望纠正错误至少足以做到这一点有序关闭

任何打开的文件。


在非交互式代码（如嵌入式系统）中，正确的响应可能是
可能是在将错误

消息写入稍后可以恢复的区域之后重启或暂停系​​统。这可能是你能做的所有事情。

我可以看到，将它用于常见的错误是不好的风格，但真正的呢？很少遇到的异常错误？

这取决于错误的严重程度。在某些应用程序中我已经工作了一些'断言''类型的宏，它们具有不同的严重程度和行动，取决于它是否是编译为

调试或生产。例如：


向用户输出消息并继续

将消息输出到本地文件并继续

输出到系统日志并继续

输出到控制台并继续

任何一个和核心转储中止

任何这些和中止与没有核心转储

中止没有尝试输出任何东西，因为那会失败

重新启动系统


如果你正在工作在一个团队中，那些东西应该已经按照标准程序来规定，如果你刚开始那么项目设计师

应该做出那些决定。 />

Chris C

Rob Thorpe写道：

一般情况下，
在生产代码中使用断言被认为是不好的做法吗？

如果编写一个与断言相同的宏，那么无论NDEBUG的状态如何都会继续工作？
我可以看到，将它用于常见的错误是不好的风格，
但真正特殊的错误会怎样呢？

你很困惑。


断言宏用于捕获编程错误（错误）。

之后您已完成开发，测试和调试

您的应用程序，您只需定义NDEBUG

并在发布生产代码之前重新编译您的应用程序。

不要编辑你的代码来删除断言的调用

因为这只是提供了引入新bug的机会。


来自assert宏的诊断对用户没用大概

谁可能不是程序员自己。

如果您在不停用断言宏的情况下发布代码，

意味着你仍在调试代码

，并且您希望用户帮助您测试您的c ode。

你可能不应该把这样的代码称为生产代码。


永远不要使用断言宏来捕获异常（你称之为错误） ）。

例外是预期但不可预测的事件

这是无法阻止的，但必须在它们发生时进行处理。

相比之下，错误是意外的但可预测的错误

（一旦被发现）

无法处理除了通过修复bug

然后再防止它们再次发生。


没有宏捕获异常。

您必须编写特殊代码来检测和处理异常。

In general, is it considered bad practice to use asserts in production
code?

What about writing a macro that does the same as assert but continues
to work regardless of the state of NDEBUG?

I can see that it would be poor style to use it for commonly
encountered errors, but what about truly exceptional errors that would
rarely if ever be encountered?

解决方案

Rob Thorpe wrote:

In general, is it considered bad practice to use asserts in production
code?

What about writing a macro that does the same as assert but continues
to work regardless of the state of NDEBUG?

I can see that it would be poor style to use it for commonly
encountered errors, but what about truly exceptional errors that would
rarely if ever be encountered?

The answer is, it depends.

You have to consider for your specific application what is best.
Possibilities include:

1) Abort the program with an appropriate message.
This can prevent incorrect results from being given and so in a
situation where no answer is better than an incorrect answer (or
corrupting a database for example) this might be the best thing.

2) Return an error status to the calling function.
If the calling function does not handle the error this could lead to
incorrect results or a crash.

3) Reboot the system (most likely to be an option on an embedded
system).

4) Attempt to recover the situation and fall back on 1, 2 or 3 if the
correction appears not to work.

For some items such as a video recorder, option 4 falling back to 3
might be the best solution. For one application I am working on option 1
is best for a lot of errors (prevents the data being corrupted and all
the work required to fix the data) but option 4 falling back to 1 is the
best solution for other types of problem.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

On 23 Mar 2005 03:15:46 -0800, Rob Thorpe
<ro***********@antenova.com> wrote:

In general, is it considered bad practice to use asserts in production
code?
I don''t think there is any ''general'' opinion, it''s largely whatever your
employers or customers think. If you mean "leave them in the code with
NDEBUG defined so that they do nothing" I don''t see any problem leaving
them there.
What about writing a macro that does the same as assert but continues
to work regardless of the state of NDEBUG?
If it''s in interactive code (by which I mean that the user starts the
application and can see error messages) then I don''t think that the
default C assert mechanism is normally appropriate. If I''m using a word
processor, for example, I don''t want it to exit with a bit of source
code on a command line and/or a core dump, it would be a lot better to
catch the error and display a meaningful message to the user (and
hopefully correct the error at least enough to do an orderly closedown
of any open files).

In non-interactive code (like embedded systems) the correct response may
well be to reboot or halt the system, possibly after writing the error
message into an area from which it can be recovered later. That may
well be all you can do.
I can see that it would be poor style to use it for commonly
encountered errors, but what about truly exceptional errors that would
rarely if ever be encountered?

It depends on the severity of the error. In some applications I''ve
worked on there have been a set of ''assert'' type macros with differing
degrees of severity and actions depending on whether it was compiled as
debug or production. For instance:

Output a message to the user and continue
Output a message to a local file and continue
Output to the system log and continue
Output to the console and continue
Any of those and abort with a core dump
Any of those and abort with no core dump
Abort without trying to output anything because that will fail
Reboot the system

If you''re working in a team those things should already be laid down as
standard procedure, if you''re starting out then the project designer
should make those sorts of decisions.

Chris C

Rob Thorpe wrote:

In general,
is it considered bad practice to use asserts in production code?

What about writing a macro that does the same as assert
but continues to work regardless of the state of NDEBUG?

I can see that
it would be poor style to use it for commonly encountered errors,
but what about truly exceptional errors
that would rarely if ever be encountered?

You are confused.

The assert macro is designed to trap programming errors (bugs).
After you have finished developing, testing and debugging
your application program, you simply define NDEBUG
and recompile your application before releasing the "production code".
Don''t edit your code to remove invocations of assert
because that just provides an opportunity to introduce new bugs.

Diagnostics from assert macros are of no use to users
who may not be programmers themselves.
If you release code without deactivating assert macros,
it means that you are still debugging the code
and that you expect users to assist you in testing your code.
You probably shouldn''t call such code "production code".

Never use the assert macro to trap exceptions (what you call errors).
Exceptions are expected but unpredictable events
which cannot be prevented but must be handled when they occur.
By contrast, bugs are unexpected but predictable errors
(once they have been discovered)
that cannot be "handled" except by fixing the bug
and then they are prevented from ever occurring again.

There are no "macros" to trap exceptions.
You must write ad hoc code to detect and handle exceptions.

这篇关于使用assert.h的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！