断言异常：场景是什么 [英] assert to exception : what is the scenario

问题描述

我的代码中有很多assert（）调用，现在我正在考虑用异常替换

。我想要做这个改变的原因是，随着程序变得越来越大，很难测试所有角落

的情况，因此断言（）不像以前那样好。问题

如果有一些非常糟糕的东西没有被

assert（）捕获，那么在运行时，程序很可能会崩溃。这是最糟糕的用户体验。


异常至少更好，因为它具有优雅的优点。退出。


之前我没有使用异常因为我被告知gcc3.2.2不支持

异常非常好，现在我的公司正在使用gcc 3.2。 3我被告知

最好处理异常。 （这是真的吗？）


我目前的计划是做一些编辑器字符串替换，所以

断言（）是例外。 />

有一点是，我使用了lofs的assert（），其中一些是非常深的

函数调用链栈，那就意味着我需要添加 ;抛出

例外声明几乎所有的功能。


虽然我只会在最顶部有一个catch语句，所以在

命令中为top函数接收例外，我需要

抛出异常从堆栈中最深的功能开始。


您如何看待我的计划，gcc3.2.3例外支持如何？


任何建议都非常感谢。

Hi,
I have many assert() call in my code, now I am considering to replace
them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner
cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is
the worst user experience.

Exception at least is better in that it has "graceful" exit.

I did not use exception before as I was told gcc3.2.2 did not support
exception very well, now my company is using gcc 3.2.3 which I am told
is better to handle exception. (Is this true?)

My current plan is to do some sort of editor string replacement so
that assert() is to be exception.

One thing is, I use lofs of assert(), some of them are in pretty deep
function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions.

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.

How do you think my plan, how about gcc3.2.3 exception support?

Any suggestion is highly appreciated.

推荐答案

< li ***** @ hotmail。 COM> skrev i en meddelelse

新闻：11 ********************** @ g14g2000cwa.googlegr oups.com ...

<li*****@hotmail.com> skrev i en meddelelse
news:11**********************@g14g2000cwa.googlegr oups.com...

我的代码中有很多assert（）调用，现在我正在考虑用异常替换它们。我想要做这个改变的原因是，随着程序越来越大，很难测试所有角落的情况，因此assert（）不像以前那样好用。问题
如果有一些非常糟糕的东西没有被
assert（）捕获，那么在运行时，很可能程序会崩溃。这是最糟糕的用户体验。

异常至少更好，因为它具有优雅。退出。


Assert用于调试，因此用户不应该看到它。但是，让我们假设您确实将调试代码发送给beta测试人员。在这种情况下，断言

要好得多。它给你一个核心转储，帮助你找出

问题是什么。

我之前没有使用异常因为我被告知gcc3.2.2不支持更好地处理异常。 （这是真的吗？）
不幸的是，我在这里无法帮助你。
我目前的计划是进行某种编辑器字符串替换，以使assert（）成为例外。
如果你决定坚持你的计划，你应该用另一个宏替换

断言宏。那个宏可以测试条件

并完成工作。类似

#define assert_throw（_cond）do {if（！_cond）throw

my_assert_signal（#_ cond）; } while（false）
有一点是，我使用了lofs的assert（），其中一些是非常深的
函数调用链栈，那就意味着我需要添加throw
例外几乎所有功能的声明。
编号只有当这些函数已经具有throw-specification时才会这样。

虽然我只会在顶部有一个catch语句，所以在
命令中使用top函数收到异常，我需要抛出异常从堆栈中最深的功能一路走来。

您如何看待我的计划，如何支持gcc3.2.3异常？


我相信断言仅适用于调试构建 - 不是你要发送给真实用户的
。也许你的一些断言检查你的环境，而不是你的逻辑？

任何建议都非常感谢。

Hi,
I have many assert() call in my code, now I am considering to replace
them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner
cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is
the worst user experience.

Exception at least is better in that it has "graceful" exit.

Assert is for debug, thus the user should not see that. But let us assume
that you do send your debug-code to beta-testers. In that case, the assert
is much better. It gives you a core dump that helps you find out what the
problem is.
I did not use exception before as I was told gcc3.2.2 did not support
exception very well, now my company is using gcc 3.2.3 which I am told
is better to handle exception. (Is this true?) Unfortunately, I cannot help you here.
My current plan is to do some sort of editor string replacement so
that assert() is to be exception. If you decide to hang on to your scheme, you should probably replace the
assert-macro with another macro. That macro could then test the condition
and do the job. Something like
#define assert_throw(_cond) do { if (!_cond) throw
my_assert_signal(#_cond); } while (false)
One thing is, I use lofs of assert(), some of them are in pretty deep
function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions. No. Only if those functions have a throw-specification already.

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.

How do you think my plan, how about gcc3.2.3 exception support?
I believe assert is for debug-builds only - not something you would send to
a real user. Perhaps some of your asserts check your environment instead of
your logic?

Any suggestion is highly appreciated.

/ Peter

/Peter

linq ... @ hotmail.com写道：

[e-mail] wrote:

我的代码中有很多assert（）调用，现在我正在考虑将
替换为异常。我想要做这个改变的原因是，随着程序变得越来越大，很难测试所有
极端情况，因此assert（）不能像以前一样好用。问题
如果有一些非常糟糕的东西没有被
assert（）捕获，那么在运行时，很可能程序会崩溃。这个
是最糟糕的用户体验。

异常至少更好，因为它具有优雅。退出。

Hi,
I have many assert() call in my code, now I am considering to replace them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is the worst user experience.

Exception at least is better in that it has "graceful" exit.

如果断言失败，你应该只在程序*应该*中止

的情况下使用''assert''。特别是，使用assert来强制执行程序

不变量（例如，当你找到'时，存储在容器中的值在

容器中） 。


使用*例外*错误的例外情况可能会或可能不会...... b $ b是一个恢复操作（例如，无法从池中分配内存

分配器）。


使用返回代码表示所有其他错误（例如，无法连接到

服务器，转换结果来自字符串到int失败等等。


至于测试极端情况，一种有效的方法是将您的

程序分解为（小）组件的层次结构明确

表示每种方法的合同，并从底部向上完全测试每个组件的分离。它对每种方法* * *
合约有很大的帮助（在各种各样的情况下返回什么价值，什么是未定义的行为，是什么影响<为了编写

实现和测试方法，参数等的
错误条件。如果您可以说明域名

和函数范围，那么测试它是相当简单的。


/ david

You should only use ''assert'' in cases where the program *should* abort
if the assertion fails. In particular, use assert to enforce program
invariants (e.g,. a value that you stored into a container is in the
container when you ''find'' it).

Use exceptions for *exceptional* errors for which there may or may not
be a recovery action (e.g., could not allocate memory from a pooled
allocator).

Use return codes for all other errors (e.g., could not connect to
server, result of translation from string to int failed, etc).

As for testing corner cases, an effective method is to break your
program into a hierarchy of (small) components with an explicitly
stated contract for each method, and test each component completely in
isolation from the bottom up. It helps a great deal to *state* the
contract for each method (what values are returned under various
circumstances, what is undefined behavior, what are the effects of
error conditions on arguments, etc) both for the purpose of writing the
implementation and for testing the method. If you can state the domain
and range of a function, it is fairly straightforward to test it.

/david

Peter Koch Larsen写道：

Peter Koch Larsen wrote:

< li ***** @ hotmail.com> skrev i en meddelelse
新闻：11 ********************** @ g14g2000cwa.googlegr oups.com ...

<li*****@hotmail.com> skrev i en meddelelse
news:11**********************@g14g2000cwa.googlegr oups.com...

我的代码中有很多assert（）调用，现在我正在考虑将
替换为异常。我想要做这个改变的原因是
随着程序变得越来越大，很难测试所有
极端情况，因此assert（）不像以前那样好用。
问题是如果有一些非常糟糕的东西没有被
assert（）捕获，那么在运行时，程序很可能会崩溃。这个
是最糟糕的用户体验。

异常至少更好，因为它具有优雅。退出。

Assert用于调试，因此用户不应该看到它。但是，让我们

Hi,
I have many assert() call in my code, now I am considering to replace them with exception. The reason I want to do this change is that with the program going bigger and bigger, it is hard to test all the corner cases, and thus assert() does not work as good as before. The problem is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is the worst user experience.

Exception at least is better in that it has "graceful" exit.

Assert is for debug, thus the user should not see that. But let us

假设您确实将调试代码发送给beta测试人员。在这种情况下，
断言要好得多。它给你一个核心转储，帮助你找出问题是什么
。

assume that you do send your debug-code to beta-testers. In that case, the assert is much better. It gives you a core dump that helps you find out what the problem is.

我之前没有使用异常因为我被告知gcc3.2.2没有
支持异常非常好，现在我的公司正在使用gcc 3.2.3我告诉我b $ b更好处理异常。 （这是真的吗？）不幸的是，我无法帮助你。

I did not use exception before as I was told gcc3.2.2 did not support exception very well, now my company is using gcc 3.2.3 which I am told is better to handle exception. (Is this true?) Unfortunately, I cannot help you here.

我目前的计划是进行某种编辑器字符串替换，以便断言（）是例外。

My current plan is to do some sort of editor string replacement so
that assert() is to be exception.

如果你决定坚持你的方案，你应该用另一个宏替换

If you decide to hang on to your scheme, you should probably replace

断言宏。那个宏可以测试
条件并完成工作。类似
#define assert_throw（_cond）做{if（！_cond）throw
my_assert_signal（#_ cond）; } while（false）

the assert-macro with another macro. That macro could then test the condition and do the job. Something like
#define assert_throw(_cond) do { if (!_cond) throw
my_assert_signal(#_cond); } while (false)

有一点是，我使用了lofs的assert（），其中一些是在
深度函数调用链堆栈中，那意味着我需要添加抛出
异常几乎所有功能的声明。不。只有当这些函数已经具有throw-specification时才会这样。

One thing is, I use lofs of assert(), some of them are in pretty deep function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions. No. Only if those functions have a throw-specification already.

虽然我只会在最顶部有一个catch语句，所以在
命令中接收异常的top函数，我需要
抛出异常从
堆栈中最深的函数开始。
你怎么看待我的计划，gcc3.2.3异常支持怎么样？

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.
How do you think my plan, how about gcc3.2.3 exception support?

我相信断言是仅用于debug-builds - 不是你想要

I believe assert is for debug-builds only - not something you would

发送给真实用户的东西。也许你的一些断言检查你的环境
而不是你的逻辑？

send to a real user. Perhaps some of your asserts check your environment instead of your logic?

任何建议都非常感谢。

Any suggestion is highly appreciated.

/ Peter

感谢您的回复。


就像你说的断言（）用于调试，对于我的情况assert（）调用将在优化编译中删除
，它只保留在调试版本中。


有一件事我想确定，让'' s说函数调用就像是

这个：

func1（）

- > func2（）

- > func3（）

在func3（）中抛出异常，func3（）声明抛出

异常。然后为了使func1（）接收异常，func2（）

必须声明throw expetion。这是对的吗？


这样的更多细节，

int func1（）{

...

尝试{

func2（）;

}

抓住重复{

。 ..

}

}


int func2（）抛出异常{

^^^ ^^^^^^^^^^^^^ - 我必须有这个声明，

对吗？

func3（）;

}


int func3（）抛出异常{

...

抛出异常;

}

Thanks for the reply.

Like you said assert() is for debug, for my case the assert() call will
be removed in optimized compile, it only stays in the debug version.

One thing I want to make sure, let''s say the function call is like
this:
func1()
--> func2()
--> func3()
In func3() I throw an exception, and func3() declares "throw
exception". Then in order for func1() to receive the exception, func2()
must declares "throw expetion". Is this right?

More details like this,

int func1(){
...
try {
func2();
}
catch excpetion {
...
}
}

int func2() throw exception {
^^^^^^^^^^^^^^^^ -- I must have this declaration,
right?
func3();
}

int func3() throw exception {
...
throw exception;
}

这篇关于断言异常：场景是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！