例外与状态代码 [英] Exceptions vs Status codes
问题描述
我参与了一个新项目，团队中的新成员表达了我们应该利用例外情况的强烈意见。
团队中的其他成员表示他们已被烧毁
且代码不可维护（因此现在没有使用例外）。我的
职位是我可以说服我使用例外。而且我的b $ b体验是让代码更难以调试。
团队决定我们给出例外情况走。是的进步！
我在这个问题上一直在喋喋不休地谈论我的小脑袋，我得出的结论是，异常并不像以前那样灵活状态代码。
a）出于调试目的，我们需要堆栈跟踪 - 但仅限于案例
，其中异常发生在我们认为坏的地方;事情发生了。
例如，假设我们有一个文件。无法打开的对象文件。
在大多数情况下，它没关系，我们真的不在乎，它真的不是特价，除非它是' 重要的文件。我真的不知道是否
它在较低级别（抛出异常）很重要。
我没事与psuedo堆栈跟踪例如
T func（T0 arg0，T1 arg1 ...）
尝试
{
... func magic ...
}
catch（...）
{
LOG （func，arg0，arg1 ......）; //等
throw; // rethrow
}
这看起来并不太糟糕，但它并非万无一失，因为没有人知道
哪个参数实际上在任何时间点登录都是有意义的。
我怀疑还有优化器命中，因为值必须是b $ b，以防万一异常，而在常规代码中，我们将
记录如下参数：
if（！func（v1，v2，v3））
{
LOG（警告，func（）失败，v1，v2，v3 ......）;
返回falase;
}
因此只有在警告时才会打开关卡日志值
需要隐藏。
b）知道什么会捕获异常真的很好。
我知道这是一个疯狂的想法，但如果有一个低成本抛出依赖于上下文的异常，那将会很好。我想
我们可以使用TSS变量来做到这一点，如果我们有合作
来电/投注者语义。
我知道这是一个有争议的话题，我真的不想再开始另一场
例外大战，但我真的很想听听使用
使用经验的人大型复杂项目中的例外情况以及需要避免的事情和
技术用于获得最佳的汗水。
通常的规则很明确。对于逻辑错误断言 - 绝对没有用于检测逻辑错误的异常。
2.异常应该偶尔发生在正常状态。运行代码。
3. RAII到处等等。
我对微调更感兴趣。
G
I''m involved in a new project and a new member on the team has voiced a
strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been burned
with unmaintainable code (an so are now not using exceptions). My
position is that "I can be convinced to use exceptions" and my
experience was that it let to code that was (much) more difficult to debug.
The team decided that we''d give exceptions a go. Yeah for progress !
I''ve been rattling my tiny brain on the issue and I have come to the
conclusion that exceptions are not as flexible as status codes.
a) For debugging purposes we want stack traces - but only for cases
where the exception is caught in a place we consider a "bad" thing happened.
For example, say we have a "file" object that fails to "open" the file.
In most cases, it''s ok, we don''t really care, it''s really not
exceptional except if it''s an "important" file. I really don''t know if
it''s important at the lower levels (where the exception is thrown).
I''m ok with psuedo stack trace e.g.
T func( T0 arg0, T1 arg1 ... )
try
{
... func magic ...
}
catch ( ... )
{
LOG( "func", arg0, arg1 ... ); //etc
throw; // rethrow
}
This does not look too bad but it''s not foolproof because no-one knows
which of the arguments actually make sense to log at any point in time.
I suspect there are also optimizer hits because the values need to be
stashed away "in case" of exception while in regular code we would be
logging the arguments like:
if ( ! func( v1, v2, v3 ) )
{
LOG( WARNING, "func() Failed", v1, v2, v3 ... );
return falase;
}
And hence only if "WARNING" level logging is turned on do the values
need to get stashed.
b) It would really be nice to know what is going to catch an exception.
I know this is a bit of a wild thought but it would be nice if there
was a low-cost was of throwing context dependant exceptions. I suppose
we could do that using a TSS variable if we had co-operating
caller/thrower semantics.
I know this is a contentious topic, I really don''t want to start another
exception war, but I''d really like to hear from people experienced in
using exceptions in big complex projects and the things to avoid and
techniques to use to get the best bang for sweat.
The usual rules are clear.
1. assert for logic errors - absolutely no exceptions used to detect
logic errors.
2. exceptions should occur infrequently in "normal" running of the code.
3. RAII everywhere etc.
I''m more interested in fine tuning.
G
推荐答案
* Gianni Mariani< gi ******* @ mariani.ws> schriebt：
* Gianni Mariani <gi*******@mariani.ws> schriebt:
我参与了一个新项目，团队中的新成员表达了我们应该利用例外情况的强烈意见。
<团队中的其他成员表示他们已经被烧毁了不可维护的代码（现在没有使用例外）。我的立场是我可以说服我使用例外。而且我的经验是让代码更难以调试。
团队决定我们会给出例外情况。是的进步！
虽然严格偏离主题，但知道一个团队如何除了一个不喜欢不使用异常之外的所有人来决定他们
应该使用例外情况。
我在这个问题上一直在喋喋不休地谈论我的小脑，我得出的结论是异常不如状态那么灵活码。
比较没有意义。
不要用例外替换状态代码。
或反之亦然。
a）出于调试目的，我们需要堆栈跟踪
C ++作为一种语言没有获取堆栈跟踪信息的工具，
但是几乎所有的工具都有。
- 但仅适用于在我们认为坏的地方捕获异常的情况
事情发生了。
不清楚。
例如，假设我们有一个文件无法打开的对象文件。
在大多数情况下，它没关系，我们真的不在乎，它真的不是特别的，除非它是一个重要的。文件。我真的不知道它是否在较低级别（抛出异常的地方）很重要。
不要使用例外来表明文件打开失败。
这不是违约。
文件打开失败的_normal_和_expected_行为。
异常并不表示失败。
表示违反（正常情况下）合同：一个函数无法按照设计和合同规定做任何事情。
b）知道什么会遇到异常真的很好。
我知道这是一个疯狂的想法，但如果
是一个低成本抛出依赖于上下文的话会很好例外。我想如果我们有合作的调用者/投注者语义，我们就可以使用TSS变量。
I''m involved in a new project and a new member on the team has voiced a
strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been burned
with unmaintainable code (an so are now not using exceptions). My
position is that "I can be convinced to use exceptions" and my
experience was that it let to code that was (much) more difficult to debug.
The team decided that we''d give exceptions a go. Yeah for progress !
Although strictly off-topic, it would be interesting to know how a team
where all but one favored not using exceptions, came to decide that they
should use exceptions.
I''ve been rattling my tiny brain on the issue and I have come to the
conclusion that exceptions are not as flexible as status codes.
The comparision is meaningless.
Do not replace status codes by exceptions.
Or vice versa.
a) For debugging purposes we want stack traces
C++ as a language has no facilities for obtaining stack trace information,
but nearly all tool-sets have.
- but only for cases
where the exception is caught in a place we consider a "bad" thing happened.
Unclear.
For example, say we have a "file" object that fails to "open" the file.
In most cases, it''s ok, we don''t really care, it''s really not
exceptional except if it''s an "important" file. I really don''t know if
it''s important at the lower levels (where the exception is thrown).
Do not use exceptions to indicate that a file open failed.
It''s not a breach of contract.
It''s _normal_ and _expected_ behavior that a file open fails.
An exception does not indicate failure.
It indicates breach of (normal case) contract: that a function wasn''t able
to do whatever it was designed and contractually obligated to do.
b) It would really be nice to know what is going to catch an exception.
I know this is a bit of a wild thought but it would be nice if there
was a low-cost was of throwing context dependant exceptions. I suppose
we could do that using a TSS variable if we had co-operating
caller/thrower semantics.
语言C有一个像你梦想的那样的设施。它被称为
''longjmp''。但是，在C ++中不支持，除非使用C ++
作为C - 例如没有需要销毁的基于堆栈的对象。
但你为什么要_want_这样的意大利面呢？
-
答：因为它弄乱了人们通常阅读文字的顺序。
问：为什么顶级发布这么糟糕的事情？
A：热门帖子。
问：usenet和电子邮件中最烦人的事情是什么？
The language C has a facility like the one you dream of. It''s called
''longjmp''. However, that''s not supported in C++ except when using C++
as C -- e.g. no stack based objects that need to be destroyed.
But why would you _want_ such spaghetti?
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Gianni Mariani写道：
< snip>
Gianni Mariani wrote:
<snip>
我知道这是一个有争议的话题，我真的不想再开始另一场
异常战争，但我真的很喜欢听取那些在大型复杂项目中使用例外情况以及要避免的事情以及使用技术来获得最佳效果的人们的经验。
通常的规则很明确。
1.断言逻辑错误 - 绝对没有用于检测逻辑错误的例外。
2.异常应该偶尔发生在正常错误中。运行代码。
3. RAII无处不在等。
I know this is a contentious topic, I really don''t want to start another
exception war, but I''d really like to hear from people experienced in
using exceptions in big complex projects and the things to avoid and
techniques to use to get the best bang for sweat.
The usual rules are clear.
1. assert for logic errors - absolutely no exceptions used to detect
logic errors.
2. exceptions should occur infrequently in "normal" running of the code.
3. RAII everywhere etc.
我想提供的一点建议就是有一个基本的异常类
包含文件，行和文本成员。这涵盖了大部分
异议。你知道抛出异常的地方和原因。
你的异常基础构造函数也可以兼作你的记录器。
我倾向于使用抛出这样的异常的宏，
#define Whinge（info）抛出异常（（info），__ FILE __，_ _ _ ____）
你可以使用它来制作一个''软断言''。
如果需要，使用例外'what（）成员打印出详细信息。
如果您使用像cppunit这样的单元测试框架，非常方便。
Ian
One bit of advice I''d like to offer is to have a base exception class
that has file, line and text members. This covers most of the
objections. You know where the exception was thrown and why.
Your exception base constructor can also double as your logger.
I tend to use a macro to throw such an exception,
#define Whinge( info ) throw Exception( (info), __FILE__, __LINE__ )
You can use this to make a ''soft assert''.
Use the exception''s what() member to print out the details if required.
Very handy if you use a unit test framework like cppunit.
Ian
Alf P. Steinbach发布：
Alf P. Steinbach posted:
* Gianni Mariani< gi ******* @ mariani.ws> schriebt：
* Gianni Mariani <gi*******@mariani.ws> schriebt:
我参与了一个新项目，团队中的新成员表达了我们应该利用例外的强烈意见。
<团队中的其他成员表示他们已被烧毁了不可维护的代码（现在没有使用例外）。
我的立场是我可以说服我使用例外 ;而且我的经验是让代码更难以调试。
团队决定我们会给出例外情况。是的进步！
I''m involved in a new project and a new member on the team has voiced
a strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been
burned with unmaintainable code (an so are now not using exceptions).
My position is that "I can be convinced to use exceptions" and my
experience was that it let to code that was (much) more difficult to
debug.
The team decided that we''d give exceptions a go. Yeah for progress !
虽然严格偏离主题，但知道一个团队如何除了一个人不喜欢不使用异常之外的所有人来决定
他们应该使用例外。
Although strictly off-topic, it would be interesting to know how a team
where all but one favored not using exceptions, came to decide that
they should use exceptions.
我不同意：如果主题的主题C ++对话导致团队的'b $ b偏好异常，那么它*是* topical因此，* on * -topic。
-JKop
I disagree: If topical on-topic C++ conversation leads to a team''s
preference for exceptions, then it *is* topical and hence, *on*-topic.
-JKop
这篇关于例外与状态代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
