关于C++中异常的争论何其多也，但往往是一些不合事实的误解。异常曾经是一个难以用好的语言特性，幸运的是，随着C++社区经验的积累，今天我们已经有足够的知识轻松编写异常安全的代码了，而且编写异常安全的代码一般也不会对性能造成影响。

　　使用异常还是返回错误码？这是个争论不休的话题。大家一定听说过这样的说法：只有在真正异常的时候，才使用异常。那什么是“真正异常的时候”？在回答这个问题以前，让我们先看一看程序设计中的不变式原理。

　　对象就是属性聚合加方法，如何判定一个对象的属性聚合是不是处于逻辑上正确的状态呢？这可以通过一系列的断言，最后下一个结论说：这个对象的属性聚合逻辑上是正确的或者是有问题的。这些断言就是衡量对象属性聚合对错的不变式。

　　我们通常在函数调用中，实施不变式的检查。不变式分为三类：前条件，后条件和不变式。前条件是指在函数调用之前，必须满足的逻辑条件，后条件是函数调用后必须满足的逻辑条件，不变式则是整个函数执行中都必须满足的条件。在我们的讨论中，不变式既是前条件又是后条件。前条件是必须满足的，如果不满足，那就是程序逻辑错误，后条件则不一定。现在，我们可以用不变式来严格定义异常状况了：满足前条件，但是无法满足后条件，即为异常状况。当且仅当发生异常状况时，才抛出异常。

　　关于何时抛出异常的回答中，并不排斥返回值报告错误，而且这两者是正交的。然而，从我们经验上来说，完全可以在这两者中加以选择，这又是为什么呢？事实上，当我们做出这种选择时，必然意味着接口语意的改变，在不改变接口的情况下，其实是无法选择的(试试看，用返回值处理构造函数中的错误)。通过不变式区别出正常和异常状况，还可以更好地提炼接口。

　　对于异常安全的评定，可分为三个级别：基本保证、强保证和不会失败。

　　基本保证：确保出现异常时程序（对象）处于未知但有效的状态。所谓有效，即对象的不变式检查全部通过。
　　强保证：确保操作的事务性，要么成功，程序处于目标状态，要么不发生改变。
　　不会失败：对于大多数函数来说，这是很难保证的。对于C++程序，至少析构函数、释放函数和swap函数要确保不会失败，这是编写异常安全代码的基础。

　　首先从异常情况下资源管理的问题开始.很多人可能都这么干过:

　　不要这么做!这么做只会使你的代码看上去混乱,而且会降低效率,这也是一直以来异常名声不大好的原因之一. 请借助于RAII技术来完成这样的工作:

　　这样的代码简洁、安全而且无损于效率。当你不关心或是无法处理异常时,请不要试图捕获它。并非使用try...catch才能编写异常安全的代码,大部分异常安全的代码都不需要try...catch。我承认，现实世界并非总是如上述的例子那样简单，但是这个例子确实可以代表很多异常安全代码的做法。在这个例子中，boost::scoped_ptr是auto_ptr一个更适合的替代品。

　　现在来考虑这样一个构造函数：

　　假设成员变量m_a和m_b是原始的指针类型，并且和Type内的申明顺序一致。这样的代码是不安全的，它存在资源泄漏问题，构造函数的失败回滚机制无法应对这样的问题。如果new TypeB抛出异常,new TypeA返回的资源是得不到释放机会的.曾经,很多人用这样的方法避免异常:

　　当然,这样的方法确实是能够实现异常安全的代码的,而且其中实现思想将是非常重要的,在如何实现强保证的异常安全代码中会采用这种思想.然而这种做法不够彻底，至少析构函数还是要手动完成的。我们仍然可以借助RAII技术，把这件事做得更为彻底：shared_ptr<TypeA> m_a; shared_ptr<TypeB> m_b;这样,我们就可以轻而易举地写出异常安全的代码:

　　如果你觉得shared_ptr的性能不能满足要求，可以编写一个接口类似scoped_ptr的智能指针类,在析构函数中释放资源即可。如果类设计成不可复制的，也可以直接用scoped_ptr。强烈建议不要把auto_ptr作为数据成员使用,scoped_ptr虽然名字不大好，但是至少很安全而且不会导致混乱。

　　RAII技术并不仅仅用于上述例子中，所有必须成对出现的操作都可以通过这一技术完成而不必try...catch.下面的代码也是常见的：

　　可以这样解决，先提供一个成对操作的辅助类：

　　然后，代码只需这样写：

　　清晰而优雅！继续考察这个例子,假设我们并不需要成对操作, 显然，修改scoped_lock构造函数即可解决问题。然而，往往方法名称和参数也不是那么固定的，怎么办？可以借助这样一个辅助类：

　　好了，借助boost库,我们可以这样来编写代码了：

　　我承认，这样的代码不如前面的简洁和容易理解，但是它更灵活,无论函数名称是什么，都可以拿来结对。我们可以加强对bind的运用，结合占位符和reference_wrapper,就可以处理函数参数、动态绑定变量。所有我们在catch内外的相同工作，交给pair_guard去完成即可。

　　考察前面的几个例子，也许你已经发现了，所谓异常安全的代码，竟然就是如何避免try...catch的代码，这和直觉似乎是违背的。有些时候，事情就是如此违背直觉。异常是无处不在的，当你不需要关心异常或者无法处理异常的时候，就应该避免捕获异常。除非你打算捕获所有异常，否则，请务必把未处理的异常再次抛出。try...catch的方式固然能够写出异常安全的代码，但是那样的代码无论是清晰性和效率都是难以忍受的，而这正是很多人抨击C++异常的理由。在C++的世界，就应该按照C++的法则来行事。

　　如果按照上述的原则行事，能够实现基本保证了吗？诚恳地说，基础设施有了，但技巧上还不够，让我们继续分析不够的部分。

　　对于一个方法常规的执行过程，我们在方法内部可能需要多次修改对象状态，在方法执行的中途，对象是可能处于非法状态的（非法状态 != 未知状态），如果此时发生异常，对象将变得无效。利用前述的手段，在pair_guard的析构中修复对象是可行的，但缺乏效率，代码将变得复杂。最好的办法是......是避免这么作，这么说有点不厚道，但并非毫无道理。当对象处于非法状态时，意味着此时此刻对象不能安全重入、不能共享。现实一点的做法是：

　　a.每一次修改对象，都确保对象处于合法状态
　　b.或者当对象处于非法状态时，所有操作决不会失败。

　　在接下来的强保证的讨论中细述如何做到这两点。

　　强保证是事务性的，这个事务性和数据库的事务性有区别，也有共通性。实现强保证的原则做法是：在可能失败的过程中计算出对象的目标状态，但是不修改对象，在决不失败的过程中，把对象替换到目标状态。考察一个不安全的字符串赋值方法：

　　locked_pool是为了锁定内存页。为了讨论的简单起见，我们假设只有locked_pool构造函数和allocate是可能抛出异常的，那么这段代码连基本保证也没有做到。若allocate失败，则m_data取值将是非法的。参考上面的b条目，我们可以这样修改代码：

　　现在，如果locked_pool失败，对象不发生改变。如果allocate失败，对象是一个空字符串，这既不是初始状态，也不是我们预期的目标状态，但它是一个合法状态。我们阐明了实现基本保证所需要的技巧部分，结合前述的基础设施（RAII的运用），完全可以实现基本保证了...哦,其实还是有一点疏漏，不过，那就留到最后吧。

　　继续，让上面的代码实现强保证：

　　强保证的代码多使用了一个局部变量tmp，先计算出目标状态放在tmp中，然后在安全进入目标状态，这个过程我们并没有损失什么东西（代码清晰性，性能等等）。看上去，实现强保证并不比基本保证困难多少，一般而言，也确实如此。不过，别太自信，举一种典型的很难实现强保证的例子，对于区间操作的强保证：

　　如果某个do_something失败了，range将处于什么状态？这段代码仍然做到了基本保证，但不是强保证的，根据实现强保证的基本原则，我们可以这么做：

　　似乎很简单啊！呵呵，这样的做法并非不可取，只是有时候行不通。因为我们额外付出了性能的代价，而且，这个代价可能很大。无论如何，我们阐述了实现强保证的方法，怎么取舍则由您决定了。

　　接下来讨论最后一种异常安全保证：不会失败。

　　通常，我们并不需要这么强的安全保证，但是我们至少必须保证三类过程不会失败：析构函数，释放类函数，swap。析构和释放函数不会失败，这是RAII技术有效的基石，swap不会失败，是为了“在决不失败的过程中，把对象替换到目标状态”。我们前面的所有讨论都是建立在这三类过程不会失败的基础上的，在这里，弥补了上面的那个疏漏。

　　一般而言，语言内部类型的赋值、取地址等运算是不会发生异常的，上述三类过程逻辑上也是不会发生异常的。内部运算中，除法运算可能抛出异常。但是地址访问错通常是一种错误，而不是异常，我们本应该在前条件检查中就发现的这一点的。所有不会发生异常操作的简单累加，仍然不会导致异常。

　　好了，现在我们可以总结一下编写异常安全代码的几条准则了：

　　1.只在应该使用异常的地方抛出异常
　　2.如果不知道如何处理异常，请不要捕获(截留)异常。
　　3.充分使用RAII，旁路异常。
　　4.努力实现强保证，至少实现基本保证。
　　5.确保析构函数、释放类函数和swap不会失败。

　　另外，还有一些语言细节问题，因为和这个主题有关也一并列出：

　　1.不要这样抛出异常：throw new exception;这将导致内存泄漏。
　　2.自定义类型，应该捕获异常的引用类型：catch(exception& e)或catch(const exception& e)。
　　3.不要使用异常规范，即使是空异常规范。编译器并不保证只抛出异常规范允许的异常，更多内容请参考相关书籍。

刚刚发表了《什么是契约》一文，突然发现自己通篇都在写理论，没有实例来证明。所以赶快补充一个反面案例——C++ IOStream。说是反面，不是因为IOStream库设计得不精彩（恰恰相反，你很难找到比IOStream设计更为精彩的C++库了），而是想展示一下，在没有契约概念的思想体系里，组件设计将为权责不清的错误处理付出多大的代价。

大家知道，C++ IOStream库非常经典，最先起源于Bjarne Stroustrup的Stream库，之后经过Jerry Schwartz、Martin Carroll、Andy Koenig等人的改进，成为IOStream库，并被并入Bell实验室发行的USD C++库中，广为传播。后来USD库逐渐消亡了，而IOStream由于获得广泛应用，得以幸免，并以新的形式被置于标准库中。

对于错误处理，当IOStream库诞生的时候（大约1985－1987），C++还没有异常机制。因此，Jerry Schwartz发明了这样一套错误处理机制：

例1：经典的IOStream错误处理：

  ifstream ifs("filename.txt", ios::in);
  if (!ifs) {  // 这里实施了向void*转型的操作
    // 文件打开失败，实施错误处理
  }

先测试文件是否打开，再实施具体操作，这是经典IOStream库的一个惯用法（idiom)。

我们现在设想用户没有很好地执行这个idiom：

  int val;
  ifstream ifs("filename.txt", ios::in);
  ifs >> val; 

如果filename.txt打开失败，会发生什么情况？

如果哪位还有当年的Borland C++ 3.1，可以试着测试一下。我估计是什么也不发生，或者说，程序处于极端危险的“undefined behavior”状态。

这种情况对C++库开发者来说是不能接受的。因此，尽管问题的出现是由于用户的错误（他们没有正确地测试流状态），但是由于非契约思想体系下的权责不清，IOStream库的开发者开始追求足以应对用户错误的组件开发技术。由此，IOStream开始在一个方向上被拖入了复杂性的泥潭之中。

我们看看标准库中的对付这种情况采用什么办法。标准IOStream有一个成员函数叫做exceptions()，专门用来帮助程序员切换异常模式。缺省情况下，异常触发并没有打开，所以情形跟经典IOStream库相同。如果你在操作IOStream之前如下调用：

strm.exceptions(std::ios::eofbit | std::ios::failbit |
                std::ios::badbit);
则当流不处于good状态时，执行类似 strm >> val；这样的操作时，将会抛出异常。

这样做看起来不错，是吗？

我觉得不是。请恕我C++标准的异议，这是我第一次正式对C++标准中的设计提出异议。

这种设计带来的缺点，首先是复杂。在Nicolai Josuttis的The C++ Standard Library中，对这个机制整整用了5页纸来解释，还意犹未尽。复杂的设计必然带来复杂的使用规则，而面对复杂的使用规则，用户是可以投票的，那就是你做你的，我不用！读这篇帖子的人，谁在实际项目中使用过exceptions()？事实上，我个人是害怕exception甚于害怕undefined behavior。

而对于用户来说，你可以不用，却不得不为对它付出运行性能和空间的代价。诸位有兴趣，不妨追踪一个IOStream功能的实现，看看为了支持这个异常，IOStream库的设计这耗费了多大的心力，而你的CPU又为此耗费了多少clock。

缺点之二，是异常本身的问题——即使你抓到了异常，又当如何？程序可能已经完全离开了发生异常时的执行环境，也许你连异常为什么发生都搞不清楚，谈何处理？也无非就是通知用户一声：“我完了，因为一个异常发生在XXXXXXXX处，你要报告的话给我发Email吧。” 是啊，你还能做什么呢？

我们试着用契约观点来分析这一状况，如果说“先测试，再使用”在传统上是一个idiom，那么在contract思想里上升为一个契约。对于C++来说，应该将“流处于good状态”作为一个契约，在每一个成员函数里进行检查。甚至你还可以设置一个调试期标志，专门用来核查用户是否检查过流状态。在必要的操作进行之前，你可以先用断言检查用户是否检查过流状态，满足了契约。这样一来，在契约之下，用户将被迫以正确的方式使用组件，从而大幅度简化组件开发的复杂度。

再来考虑异常。如果真正发生了异常，在Eiffel中提供了retry机制。Bjarne Stroustrup说过，retry可以做到，但是往往没有意义。为什么没有意义呢？因为C++中没有契约的思想，异常的产生可能根本就是程序员的bug。在这种情况下，无论retry多少次，结果都是一样的糟。可是在Eiffel里情形不同。如果各方面对于契约都做到很好的遵循，那么真正发生异常的时候，我们大可以比较有把握的说，这可能是一个很偶然的事件导致的。比如说网络环境下，另一个用户在那一瞬间突然对文件实施了一个操作，或者硬件的一次偶然异常。对于这种情况，“再试一次”成了合情合理的选择。我们很可能将异常扼杀在摇篮之中，从而不给上层模块带来任何影响。

谁说契约思想不伟大呢？

注：本文转自孟岩的博客(http://blog.csdn.net/myan)

假设你现在正在面试，主考不紧不慢地给出下一道题目：“请用C语言写一个类似strcpy的函数。要考虑可能发生的异常情况。” 你会怎么做呢？很明显，对方不是在考察你的编程能力，因为复制字符串实在太容易了。对方是在考察你的编程风格（习惯），或者说，要看看你编码的质量。

下面是多种可能的做法：

void
string_copy1(char* dest, const char* source)
{
assert(dest != NULL); /* 使用断言 */
assert(source != NULL);
while (*source != ‘\0′) {
*dest = *source;
++dest;
++source;
}

*dest = ‘\0′;
}

void
string_copy2(char* dest, const char* source)
{
if (dest != NULL && source != NULL) {  /* 对错误消极静默 */
while (*source != ‘\0′) {
*dest = *source;
++dest;
++source;
}

*dest = ‘\0′;
}
}

int
string_copy3(char* dest, const char* source)
{
if (dest != NULL && source != NULL) {
while (*source != ‘\0′) {
*dest = *source;
++dest;
++source;
}

*dest = ‘\0′;
return SUCCESS;  /* 返回表示正确的值 */
}
else {
errno = E_INVALIDARG;  /* 设定错误号 */
return FAILED;         /*  返回表示错误的值 */
}
}
// C++
void
string_copy4(char* dest, const char* source)
{
if (dest == NULL || source == NULL)
throw Invalid_Argument_Error();  /*  抛出异常 */

while (*source != ‘\0′) {
*dest = *source;
++dest;
++source;
}

*dest = ‘\0′;
}

如果你是主考，不知道面对这样四份答卷，你的评分如何？当然，你可以心里揣着一个“标准答案”，“顺我者昌，逆我者亡”。但是如果以认真的态度面对这四份答卷，我想很多人都会难以抉择。

因为这里涉及到了软件开发中的一个带有本质性的难题——错误处理。

历来错误处理一直是软件开发者所面临的最大困难之一。Bjarne Stroustrup在谈到其原因时说道，能够探察错误的一方不知道如何处理错误，知道如何处理错误的一方没有能力探察错误，而直接采用防御性代码来解 决，会使得程序的正常结构被打乱，从而带来更多的错误。这种困境是非常难以应对的——费心耗力而未必有回报。因此，更多的人采用鸵鸟战术，对可能发生的错 误视而不见，任其自然。

C++、Java和其他语言对错误处理问题的回答是异常机制。这种机制在正常的程序执行流之外开辟了专门的信道，专门用来在不同程序模块之间报告错误，解 决上述错误探察与处理策略分散的矛盾。然而，有了异常处理机制后，开发者开始有一种倾向，就是使用异常来处理所有的错误。我曾经就这个问题在 comp.lang.c++.moderated上展开讨论，结果是发现有相当多的人，包括Boost开发组里的很多专家，都认为异常是错误处理的通用解 决方案。

对此我不能赞同。并且我认为滥用异常比不用异常的危害更大。

The Pragmatic Programmer是一本在国外程序员中间颇为流行的书，其中在讲到错误处理时，有一句箴言：
“只在真正异常的状况下使用异常。”

书中举了一个例子，如果你需要当前目录下的一个名叫“app.dat”的文件，而这个文件不存在，那么这不叫异常状况，这是你应该预料到的、并且显式处理 的情况。而如果你要到Windows目录下寻找user.dat文件，却没找到，那才叫做异常状况——因为每一个正常运行的Windows系统都应该有这 个文件。

我非常赞成书中的那句忠告，可是究竟什么是“真正异常”的状况？书中的这个例子显然只是一个颇具感性的、寓言似的故事，具有所有寓言的共同特点——读起来觉得豁然开朗，收获很大，实际上帮不了你什么忙。这种例子对于我们的实际开发，仍然提供不了真正的帮助。

究竟应该如何看待错误？怎样才能最好地错误处理？

说实话，在这两个问题上，我们所见到的大部分语言都没有给出很好的回答。C秉承一贯风格，把所有的东西推给开发者考虑；Ada发明了异常，但是又为异常所 累（知道阿里亚纳5火箭的处女航为什么失败吗？）；C++企图将Ada的异常机制融合进自己的体系中，结果异常成了C++中最难以处理的东西；Java和 C#显然都没有耐心重新考虑错误处理这桩事，而只是简单的将C++的异常机制完善化了事。

与上述这些语言不同，Eiffel从一开始就把错误处理放在核心的位置上予以考虑，并以“契约”思想为核心，建立了整个的错误处理思想体系。在我了解的语 言里，Eiffel是对这个问题思考最为深刻一个，因此，Eiffel历来享有“高质量系统开发语言”的声誉。（事实上，Bertrand Meyer很不喜欢别人称Eiffel为“编程语言”，他反复强调，Eiffel是一个Software Development Framework。不过本文只涉及语言特性，所以姑且称Eiffel语言。）

Eiffel把软件错误产生的本质归结与“契约”的破坏。Eiffel认为，一个软件能够正常运作，正确完成任务，是需要一系列条件的。这些条件包括客观 运行环境良好，操作者操作正确，软件内部功能正确等等。因此，软件的正确运行，是环境、操作者与软件本身三方面合作的结果。相应的，系统的错误，也是由于 三者中有一方没有正确履行自己的职责而导致的。细化到软件内部，每个软件都是由若干不同的模块组成的，软件的错误，是由于某些模块没有正确履行自己的职 责。要彻底杜绝软件错误，只有分清各自模块的责任，并且建立机制，敦促各模块正确履行自己的责任，然后才有可能做到Bug-free。（鉴于系统中错综复 杂的关系，以及开发者认识能力的局限，我认为真正无错误的系统是不可能的。但是当前一般软件系统中的质量问题远远比应有的严重。）

如何保证各方恪守职责呢？Eiffel引入了契约（Contract）这个概念。这里的契约与我们通常所说的商业契约很相似，有以下几个特点：

1. 契约关系的双方是平等的，对整个bussiness的顺利进行负有共同责任，没有哪一方可以只享有权利而不承担义务。
2. 契约关系经常是相互的，权利和义务之间往往是互相捆绑在一起的；
3. 执行契约的义务在我，而核查契约的权力在人；
4. 我的义务保障的是你的利益，而你的义务保障的是我的利益；
将契约关系引入到软件开发领域，尤其是面向对象领域之后，在观念上给我们带来了几大冲击：

1. 一般的观点，在软件体系中，程序库和组件库被类比为server，而使用程序库、组件库的程序被视为client。根据这种C/S关系，我们往往对库程序 和组件的质量提出很严苛的要求，强迫它们承担本不应该由它们来承担的责任，而过分纵容client一方，甚至要求库程序去处理明显由于client错误造 成的困境。客观上导致程序库和组件库的设计和编写异常困难，而且质量隐患反而更多；同时client一方代码大多松散随意，质量低劣。这种情形，就好像在 一个权责不清的企业里，必然会养一批尸位素餐的混混，苦一批任劳任怨，不计得失的老黄牛。引入契约观念之后，这种C/S关系被打破，大家都是平等的，你需 要我正确提供服务，那么你必须满足我提出的条件，否则我没有义务“排除万难”地保证完成任务。

2. 一般认为在模块中检查错误状况并且上报，是模块本身的义务。而在契约体制下，对于契约的检查并非义务，实际上是在履行权利。一个义务，一个权利，差别极大。例如上面的代码：
if (dest == NULL) { … }
这就是义务，其要点在于，一旦条件不满足，我方（义务方）必须负责以合适手法处理这尴尬局面，或者返回错误值，或者抛出异常。而：
assert(dest != NULL);
这是检查契约，履行权利。如果条件不满足，那么错误在对方而不在我，我可以立刻“撕毁合同”，罢工了事，无需做任何多余动作。这无疑可以大大简化程序库和组件库的开发。

3. 契约所核查的，是“为保证正确性所必须满足的条件”，因此，当契约被破坏时，只表明一件事：软件系统中有bug。其意义是说，某些条件在到达我这里时，必 须已经确保为“真”。谁来确保？应该是系统中的其他模块在先期确保。如果在我这里发现契约没有被遵守，那么表明系统中其他模块没有正确履行自己的义务。就 拿上面提到的“打开文件”的例子来说，如果有一个模块需要一个FILE*，而在契约检查中发现该指针为NULL，则意味着有一个模块没有履行其义务，即 “检查文件是否存在，确保文件以正确模式打开，并且保证指针的正确性”。因此，当契约检查失败时，我们首先要知道这意味着程序员错误，而且要做的不是纠正 契约核查方，而是纠正契约提供方。换句话说，当你发现:
assert(dest != NULL);
报错时，你要做的不是去修改你的string_copy函数，而是要让任何代码在调用string_copy时确保dest指针不为空。

4. 我们以往对待“过程”或“函数”的理解是：完成某个计算任务的过程，这一看法只强调了其目标，没有强调其条件。在这种理解下，我们对于exception 的理解非常模糊和宽泛：只要是无法完成这个计算过程，均可被视为异常，也不管是我自己的原因，还是其他人的原因（典型的权责不清）。正是因为这种模糊和宽 泛，“究竟什么时候应该抛出异常”成为没有人能回答的问题。而引入契约之后，“过程”和“函数”被定义为：完成契约的过程。基于契约的相互性，如果这个契 约的失败是因为其他模块未能履行契约，本过程只需报告，无需以任何其他方式做出反应。而真正的异常状况是“对方完全满足了契约，而我依然未能如约完成任 务”的情形。这样以来，我们就给“异常”下了一个清晰、可行的定义。

5. 一般来说，在面向对象技术中，我们认为“接口”是唯一重要的东西，接口定义了组件，接口确定了系统，接口是面向对象中我们唯一需要关心的东西，接口不仅是 必要的，而且是充分的。然而，契约观念提醒我们，仅仅有接口还不充分，仅仅通过接口还不足以传达足够的信息，为了正确使用接口，必须考虑契约。只有考虑契 约，才可能实现面向对象的目标：可靠性、可扩展性和可复用性。反过来，“没有契约的复用根本就是瞎胡闹。（Bertrand Meyer语）”。

由上述观点可以看出，虽然Eiffel所倡导的Design By Contract在表象上不过是系统化的断言（assertion）机制，然而在背后，确实是完全的思想革新。正如Ivar Jacoboson访华时对《程序员》杂志所说：“我认为Bertrand Meyer的方向——Design by Contract——是正确的方向，我们都会沿着他的足迹前进。我相信，大型厂商（微软、IBM，当然还有Rational）都不会对Bertrand Meyer的成就坐视不理。所有这些厂商都会在这个方向上有所行动。”

VC开发环境之所以提供远程调试的能力，是因为有些情况下单机调试会让你崩溃掉。。。比如，调试GUI程序的WM_PAINT消息，因为要单步调试，所以调试器会对界面的重绘产生副作用（Heisenberg不确定性原理）。当然还有些别的情况也适用，比如程序在测试环境运行的好好的，但是在客户那行为总是异常，这时候如果可以TCP远程连接上去维护的话，就能通过远程调试的特性在出现状况的系统环境中排错~

        下面来说一下具体的做法。先明确下概念，远程调试嘛，自然是两个机器之间调试。程序运行在目标机器上，调试器运行在本机。当然，目标机器上还是要有少许辅助程序才能跟本机的调试器connect上，以便通讯。一般来说，只需要copy四个文件到目标机器上就行了：MSVCMON.EXE、DM.DLL、TLN0T.DLL和MSDIS110.DLL。这四个文件都能在VC6目录的Common\MSDEV98\Bin目录下面找到。copy过去之后，运行msvcom.exe，看下图片~

有个Settings的按钮，不用管。直接点Connect就行了~

接着看看本机这边调试器的设置。首先设置好远程调试开关，在Build菜单下有个Debuger Remote Connecting的子菜单，点之。出现个窗口，默认是在Local项，我们要选的是Network(TCP/IP)，然后点设定。会弹出一个对话框，输入目标机器的ip或者机器名，最后点OK就行了。

接下来把工程打开，设置最后一步。假设生成的可执行程序名为RemoteDebug.exe，在目标机器上的路径为d:\Prj\Remote.exe，那么，在本机的Project Settings里面，选择Debug页面的Remote executable path and file name下面的编辑框中输入目标机器中程序的路径：d:\Prj\RemoteDebug.exe。注意，这里写的是从目标机器的角度所看到的路径。

然后编译一下程序，把新编译出来的RemoteDebug.exe复制到目标机器的d:\Prj下面，就可以在本机像平常一样调试了。

#define _CRTDBG_MAP_ALLOC  #include<stdlib.h>  #include<crtdbg.h>   #include "debug_new.h" 

　　MSDN 如是说：“必须保证上面声明的顺序，如果改变了顺序，可能不能正常工作。”至于这是为什么，我们不得而知。MS 的老大们经常这样故弄玄虚。
针对非 MFC 程序，再加上周星星的头文件：debug_new.h，当然如果不加这一句，也能检测出内存泄漏，但是你无法确定在哪个源程序文件中发生泄漏。Output 输出只告诉你在 crtsdb.h 中的某个地方有内存泄漏。我测试时 REG_DEBUG_NEW 没有起作用。加不加这个宏都可以检测出发生内存分配泄漏的文件。
其次，一旦添加了上面的声明，你就可以通过在程序中加入下面的代码来报告内存泄漏信息了：

      _CrtDumpMemoryLeaks(); 

Detected memory leaks!  Dumping objects ->  c:\Program Files\...\include\crtdbg.h(552) : {45} normal block at 0x00441BA0, 2 bytes long.  Data: <AB> 41 42  c:\Program Files\...\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long.  Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  c:\Program Files\...\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long.  Data: < C > E8 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete. 

更具体的细节请参考本文附带的源代码文件。

下面是我看过 MSDN 资料后，针对“如何使用 CRT 调试功能来检测内存泄漏？”的问题进行了一番编译和整理，希望对大家有用。如果你的英文很棒，那就不用往下看了，建议直接去读 MSDN 库中的技术原文。
C/C++ 编程语言的最强大功能之一便是其动态分配和释放内存，但是中国有句古话：“最大的长处也可能成为最大的弱点”，那么 C/C++ 应用程序正好印证了这句话。在 C/C++ 应用程序开发过程中，动态分配的内存处理不当是最常见的问题。其中，最难捉摸也最难检测的错误之一就是内存泄漏，即未能正确释放以前分配的内存的错误。偶尔发生的少量内存泄漏可能不会引起我们的注意，但泄漏大量内存的程序或泄漏日益增多的程序可能会表现出各种 各样的征兆：从性能不良（并且逐渐降低）到内存完全耗尽。更糟的是，泄漏的程序可能会用掉太多内存，导致另外一个程序垮掉，而使用户无从查找问题的真正根源。此外，即使无害的内存泄漏也可能殃及池鱼。
幸运的是，Visual Studio 调试器和 C 运行时 (CRT) 库为我们提供了检测和识别内存泄漏的有效方法。下面请和我一起分享收获——如何使用 CRT 调试功能来检测内存泄漏？

1. 如何启用内存泄漏检测机制？
   • 使用 _CrtSetDbgFlag
   • 设置 CRT 报告模式
2. 解释内存块类型
3. 如何在内存分配序号处设置断点？
4. 如何比较内存状态？
5. 结论

如何启用内存泄漏检测机制？

　　VC++ IDE 的默认状态是没有启用内存泄漏检测机制的，也就是说即使某段代码有内存泄漏，调试会话的 Output 窗口的 Debug 页不会输出有关内存泄漏信息。你必须设定两个最基本的机关来启用内存泄漏检测机制。

一是使用调试堆函数：

#define _CRTDBG_MAP_ALLOC  #include<stdlib.h>  #include<crtdbg.h> 

注意：#include 语句的顺序。如果更改此顺序，所使用的函数可能无法正确工作。

通过包含 crtdbg.h 头文件，可以将 malloc 和 free 函数映射到其“调试”版本 _malloc_dbg 和 _free_dbg，这些函数会跟踪内存分配和释放。此映射只在调试（Debug）版本（也就是要定义 _DEBUG）中有效。发行版本（Release）使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基础版本映射到对应的“调试”版本。该语句不是必须的，但如果没有该语句，那么有关内存泄漏的信息会不全。

二是在需要检测内存泄漏的地方添加下面这条语句来输出内存泄漏信息：

_CrtDumpMemoryLeaks();

Detected memory leaks! Dumping objects -> C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long. Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long. Data: < C > 08 02 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete.

如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏的输出是这样的：

Detected memory leaks! Dumping objects -> {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  {44} normal block at 0x00441BD0, 33 bytes long. Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  {43} normal block at 0x00441C20, 40 bytes long. Data: < C > C0 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete.

xx}：花括弧内的数字是内存分配序号，本文例子中是 {45}，{44}，{43}； block：内存块的类型，常用的有三种：normal（普通）、client（客户端）或 CRT（运行时）；本文例子中是：normal block；  用十六进制格式表示的内存位置，如：at 0x00441BA0 等； 以字节为单位表示的内存块的大小，如：32 bytes long；  前 16 字节的内容（也是用十六进制格式表示），如：Data: <AB> 41 42 等；

　　仔细观察不难发现，如果定义了 _CRTDBG_MAP_ALLOC ，那么在内存分配序号前面还会显示在其中分配泄漏内存的文件名，以及文件名后括号中的数字表示发生泄漏的代码行号，比如：

C:\Temp\memleak\memleak.cpp(15) 

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

　　这条语句无论程序在什么地方退出都会自动调用 _CrtDumpMemoryLeaks。注意：这里必须同时设置两个位域标志：_CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。

设置 CRT 报告模式

默认情况下，_CrtDumpMemoryLeaks 将内存泄漏信息 dump 到 Output 窗口的 Debug 页， 如果你想将这个输出定向到别的地方，可以使用 _CrtSetReportMode 进行重置。如果你使用某个库，它可能将输出定向到另一位置。此时，只要使用以下语句将输出位置设回 Output 窗口即可：

_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

有关使用 _CrtSetReportMode 的详细信息，请参考 MSDN 库关于 _CrtSetReportMode 的描述。

解释内存块类型

前面已经说过，内存泄漏报告中把每一块泄漏的内存分为 normal（普通块）、client（客户端块）和 CRT 块。事实上，需要留心和注意的也就是 normal 和 client，即普通块和客户端块。

• normal block（普通块）：这是由你的程序分配的内存。
• client block（客户块）：这是一种特殊类型的内存块，专门用于 MFC 程序中需要析构函数的对象。MFC new 操作符视具体情况既可以为所创建的对象建立普通块，也可以为之建立客户块。
• CRT block（CRT 块）：是由 C RunTime Library 供自己使用而分配的内存块。由 CRT 库自己来管理这些内存的分配与释放，我们一般不会在内存泄漏报告中发现 CRT 内存泄漏，除非程序发生了严重的错误（例如 CRT 库崩溃）。

除了上述的类型外，还有下面这两种类型的内存块，它们不会出现在内存泄漏报告中：

• free block（空闲块）：已经被释放(free)的内存块。
• Ignore block（忽略块）：这是程序员显式声明过不要在内存泄漏报告中出现的内存块。

如何在内存分配序号处设置断点？

　　在内存泄漏报告中，的文件名和行号可告诉分配泄漏的内存的代码位置，但仅仅依赖这些信息来了解完整的泄漏原因是不够的。因为一个程序在运行时，一段分配内存的代码可能会被调用很多次，只要有一次调用后没有释放内存就会导致内存泄漏。为了确定是哪些内存没有被释放，不仅要知道泄漏的内存是在哪里分配的，还要知道泄漏产生的条件。这时内存分配序号就显得特别有用——这个序号就是文件名和行号之后的花括弧里的那个数字。
例如，在本文例子代码的输出信息中，“45”是内存分配序号，意思是泄漏的内存是你程序中分配的第四十五个内存块：

Detected memory leaks! Dumping objects -> C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  ...... Object dump complete. 

　　CRT 库对程序运行期间分配的所有内存块进行计数，包括由 CRT 库自己分配的内存和其它库（如 MFC）分配的内存。因此，分配序号为 N 的对象即为程序中分配的第 N 个对象，但不一定是代码分配的第 N 个对象。（大多数情况下并非如此。）
这样的话，你便可以利用分配序号在分配内存的位置设置一个断点。方法是在程序起始附近设置一个位置断点。当程序在该点中断时，可以从 QuickWatch（快速监视）对话框或 Watch（监视）窗口设置一个内存分配断点：

例如，在 Watch 窗口中，在 Name 栏键入下面的表达式：

_crtBreakAlloc

如果要使用 CRT 库的多线程 DLL 版本（/MD 选项），那么必须包含上下文操作符，像这样：

{,,msvcrtd.dll}_crtBreakAlloc

　　现在按下回车键，调试器将计算该值并把结果放入 Value 栏。如果没有在内存分配点设置任何断点，该值将为 –1。
用你想要在其位置中断的内存分配的分配序号替换 Value 栏中的值。例如输入 45。这样就会在分配序号为 45 的地方中断。 
在所感兴趣的内存分配处设置断点后，可以继续调试。这时，运行程序时一定要小心，要保证内存块分配的顺序不会改变。当程序在指定的内存分配处中断时，可以查看 Call Stack（调用堆栈）窗口和其它调试器信息以确定分配内存时的情况。如果必要，可以从该点继续执行程序，以查看对象发生了什么情况，或许可以确定未正确释放对象的原因。
尽管通常在调试器中设置内存分配断点更方便，但如果愿意，也可在代码中设置这些断点。为了在代码中设置一个内存分配断点，可以增加这样一行（对于第四十五个内存分配）：

_crtBreakAlloc = 45;

你还可以使用有相同效果的 _CrtSetBreakAlloc 函数：

_CrtSetBreakAlloc(45);

如何比较内存状态？

　　定位内存泄漏的另一个方法就是在关键点获取应用程序内存状态的快照。CRT 库提供了一个结构类型 _CrtMemState。你可以用它来存储内存状态的快照：

_CrtMemState s1, s2, s3;

　　若要获取给定点的内存状态快照，可以向 _CrtMemCheckpoint 函数传递一个 _CrtMemState 结构。该函数用当前内存状态的快照填充此结构：

_CrtMemCheckpoint( &s1 );

　　通过向 _CrtMemDumpStatistics 函数传递 _CrtMemState 结构，可以在任意地方 dump 该结构的内容：

_CrtMemDumpStatistics( &s1 );

该函数输出如下格式的 dump 内存分配信息：

0 bytes in 0 Free Blocks. 75 bytes in 3 Normal Blocks. 5037 bytes in 41 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 5308 bytes. Total allocations: 7559 bytes.

　　若要确定某段代码中是否发生了内存泄漏，可以通过获取该段代码之前和之后的内存状态快照，然后使用 _CrtMemDifference 比较这两个状态：

_CrtMemCheckpoint( &s1 );// 获取第一个内存状态快照  // 在这里进行内存分配  _CrtMemCheckpoint( &s2 );// 获取第二个内存状态快照  // 比较两个内存快照的差异 if ( _CrtMemDifference( &s3, &s1, &s2) )      _CrtMemDumpStatistics( &s3 );// dump 差异结果

　　顾名思义，_CrtMemDifference 比较两个内存状态（前两个参数），生成这两个状态之间差异的结果（第三个参数）。在程序的开始和结尾放置 _CrtMemCheckpoint 调用，并使用 _CrtMemDifference 比较结果，是检查内存泄漏的另一种方法。如果检测到泄漏，则可以使用 _CrtMemCheckpoint 调用通过二进制搜索技术来分割程序和定位泄漏。

结论

尽管 VC ++ 具有一套专门调试 MFC 应用程序的机制，但本文上述讨论的内存分配很简单，没有涉及到 MFC 对象，所以这些内容同样也适用于 MFC 程序。在 MSDN 库中可以找到很多有关 VC++ 调试方面的资料，如果你能善用 MSDN 库，相信用不了多少时间你就有可能成为调试高手。

本人水平不高，谬误在所难免，请大家拍砖，不要客气。顺祝大家圣诞快乐！

JerryZ 于 2004 年平安夜，

调试方法和技巧

作者：非凡

便于调试的代码风格：

1. 不用全局变量
2. 所有变量都要初始化，成员变量在构造函数中初始化
3. 尽量使用const
4. 详尽的注释

VC++编译选项：

1. 总是使用/W4警告级别
2. 在调试版本里总是使用/GZ编译选项，用来发现在Release版本中才有的错误
3. 没有警告的编译：保证在编译后没有任何警告，但是在消除警告前要进行仔细检查

调试方法：

1、使用 Assert（原则：尽量简单）
assert只在debug下生效，release下不会被编译。

例子：

char* strcpy(char* dest,char* source) { 	assert(source!=0); 	assert(dest!=0); 	char* returnstring = dest; 	 	while((*dest++ = *source++)!= ‘\0’) 	{ 		; 	} 	return returnstring; }      

2、防御性的编程

例子：

char* strcpy(char* dest,char* source) { 	if(source == 0) 	{ 		assert(false); 		reutrn 0; 	}  	if(dest == 0) 	{ 		assert(false); 		return 0; 	} 	char* returnstring = dest; 	while((*dest++ = *source++)!= ‘\0’) 	{ 		; 	} 	return returnstring; }      

3、使用Trace

以下的例子只能在debug中显示，

例子：

a)、TRACE

CString csTest ＝ “test”； TRACE（“CString is ％s\n”，csTest）；

b)、ATLTRACE

c)、afxDump

CTime time = CTime::GetCurrentTime(); #ifdef _DEBUG afxDump << time << “\n”; #endif

4、用GetLastError来检测返回值，通过得到错误代码来分析错误原因

5、把错误信息记录到文件中

异常处理

程序设计时一定要考虑到异常如何处理，当错误发生后，不应简单的报告错误并退出程序，应当尽可能的想办法恢复到出错前的状态或者让程序从头开始运行，并且对于某些错误，应该能够容错，即允许错误的存在，但是程序还是能够正常完成任务。

调试技巧

1、VC++中F5进行调试运行

a)、在output Debug窗口中可以看到用TRACE打印的信息
b)、 Call Stack窗口中能看到程序的调用堆栈

2、当Debug版本运行时发生崩溃，选择retry进行调试，通过看Call Stack分析出错的位置及原因
3、使用映射文件调试

a)、创建映射文件：Project settings中link项，选中Generate mapfile，输出程序代码地址：/MAPINFO: LINES，得到引出序号：/MAPINFO: EXPORTS。
b)、程序发布时，应该把所有模块的映射文件都存档。
c)、查看映射文件：见” 通过崩溃地址找出源代码的出错行”文件。

4、可以调试的Release版本

Project settings中C++项的Debug Info选择为Program Database，Link项的Debug中选择Debug Info和Microsoft format。

5、查看API的错误码，在watch窗口输入@err可以查看或者@err,hr，其中”,hr”表示错误码的说明。
6、Set Next Statement：该功能可以直接跳转到指定的代码行执行，一般用来测试异常处理的代码。
7、调试内存变量的变化：当内存发生变化时停下来。

常见错误

1、在函数返回的时候程序崩溃的原因

a)、写自动变量越界
b)、函数原型不匹配

2、MFC

a)、使用错误的函数原型处理用户定义消息

正确的函数原型为：

afx_msg LRESULT OnMyMessage(WPARAM wParam,LPARAM lParam);

3、谨慎使用TerminateThread：使用TerminateThread会造成资源泄漏，不到万不得已，不要使用。

4、使用_beginthreadex，不要使用Create Thread来常见线程。

参考资料：
《Windows程序调试》

功能强大的vc6调试器


作者：yy2better

  要成为一位优秀的软件工程师，调试能力必不可缺。本文将较详细介绍VC6调试器的主要用法。 
  windows平台的调试器主要分为两大类： 
  1 用户模式(user-mode)调试器：它们都基于win32 Debugging API，有使用方便的界面，主要用于调试用户模式下的应用程序。这类调试器包括Visual C++调试器、WinDBG、BoundChecker、Borland C++ Builder调试器、NTSD等。 
  2 内核模式(kernel-mode)调试器：内核调试器位于CPU和操作系统之间，一旦启动，操作系统也会中止运行，主要用于调试驱动程序或用户模式调试器不易调试的程序。这类调试器包括WDEB386、WinDBG和softice等。其中WinDBG和softice也可以调试用户模式代码。 
  国外一位调试高手曾说，他70％调试时间是在用VC++，其余时间是使用WinDBG和softice。毕竟，调试用户模式代码，VC6调试器的效率是非常高的。因此，我将首先在本篇介绍VC6调试器的主要用法，其他调试器的用法及一些调试技能在后续文章中阐述。 

一 位置断点（Location Breakpoint） 
  大家最常用的断点是普通的位置断点，在源程序的某一行按F9就设置了一个位置断点。但对于很多问题，这种朴素的断点作用有限。譬如下面这段代码：

void CForDebugDlg::OnOK() 	 { 	for (int i = 0; i < 1000; i++)	//A 	{ 		int k = i * 10 - 2;	//B 		SendTo(k);		//C 		int tmp = DoSome(i);	//D 		int j = i / tmp;	//E 	} }             

  执行此函数，程序崩溃于E行，发现此时tmp为0，假设tmp本不应该为0，怎么这个时候为0呢？所以最好能够跟踪此次循环时DoSome函数是如何运行的，但由于是在循环体内，如果在E行设置断点，可能需要按F5（GO）许多次。这样手要不停的按，很痛苦。使用VC6断点修饰条件就可以轻易解决此问题。步骤如下。 
  1 Ctrl+B打开断点设置框，如下图： 
 
Figure 1设置高级位置断点 
  2 然后选择D行所在的断点，然后点击condition按钮，在弹出对话框的最下面一个编辑框中输入一个很大数目，具体视应用而定，这里1000就够了。 
  3 按F5重新运行程序，程序中断。Ctrl+B打开断点框，发现此断点后跟随一串说明：...487 times remaining。意思是还剩下487次没有执行，那就是说执行到513（1000－487）次时候出错的。因此，我们按步骤2所讲，更改此断点的skip次数,将1000改为513。 
  4 再次重新运行程序，程序执行了513次循环，然后自动停在断点处。这时，我们就可以仔细查看DoSome是如何返回0的。这样，你就避免了手指的痛苦，节省了时间。 
  再看位置断点其他修饰条件。如Figure 1所示，在“Enter the expression to be evaluated:”下面，可以输入一些条件，当这些条件满足时，断点才启动。譬如，刚才的程序，我们需要i为100时程序停下来，我们就可以输入在编辑框中输入“i==100”。 
  另外，如果在此编辑框中如果只输入变量名称，则变量发生改变时，断点才会启动。这对检测一个变量何时被修改很方便，特别对一些大程序。 
  用好位置断点的修饰条件，可以大大方便解决某些问题。 

二 数据断点（Data Breakpoint） 
  软件调试过程中，有时会发现一些数据会莫名其妙的被修改掉（如一些数组的越界写导致覆盖了另外的变量），找出何处代码导致这块内存被更改是一件棘手的事情（如果没有调试器的帮助）。恰当运用数据断点可以快速帮你定位何时何处这个数据被修改。譬如下面一段程序：

#include "stdafx.h" #include   int main(int argc, char* argv[]) { 	char szName1[10]; 	char szName2[4]; 	strcpy(szName1,"shenzhen");		 	printf("%s\n", szName1);		//A  	strcpy(szName2, "vckbase");		//B 	printf("%s\n", szName1); 	printf("%s\n", szName2);  	return 0; }       

  这段程序的输出是

      	szName1: shenzhen 	szName1: ase 	szName2: vckbase      

szName1何时被修改呢？因为没有明显的修改szName1代码。我们可以首先在A行设置普通断点，F5运行程序，程序停在A行。然后我们再设置一个数据断点。如下图： 
 
Figure 2 数据断点 
  F5继续运行，程序停在B行，说明B处代码修改了szName1。B处明明没有修改szName1呀？但调试器指明是这一行，一般不会错，所以还是静下心来看看程序，哦，你发现了：szName2只有4个字节，而strcpy了7个字节，所以覆写了szName1。 
  数据断点不只是对变量改变有效，还可以设置变量是否等于某个值。譬如，你可以将Figure 2中红圈处改为条件”szName2[0]==''''y''''“,那么当szName2第一个字符为y时断点就会启动。 
  可以看出，数据断点相对位置断点一个很大的区别是不用明确指明在哪一行代码设置断点。 

三 其他 
  1 在call stack窗口中设置断点，选择某个函数，按F9设置一个断点。这样可以从深层次的函数调用中迅速返回到需要的函数。 
  2 Set Next StateMent命令（debug过程中，右键菜单中的命令） 
  此命令的作用是将程序的指令指针（EIP）指向不同的代码行。譬如，你正在调试上面那段代码，运行在A行，但你不愿意运行B行和C行代码，这时，你就可以在D行，右键，然后“Set Next StateMent”。调试器就不会执行B、C行。只要在同一函数内，此指令就可以随意跳前或跳后执行。灵活使用此功能可以大量节省调试时间。 
  3 watch窗口 
  watch窗口支持丰富的数据格式化功能。如输入0x65,u，则在右栏显示101。 
  实时显示windows API调用的错误：在左栏输入@err,hr。 
  在watch窗口中调用函数。提醒一下，调用完函数后马上在watch窗口中清除它，否则，单步调试时每一步调试器都会调用此函数。 
  4 messages断点不怎么实用。基本上可以用前面讲述的断点代替。 
总结 
  调试最重要的还是你要思考，要猜测你的程序可能出错的地方，然后运用你的调试器来证实你的猜测。而熟练使用上面这些技巧无疑会加快这个过程。最后，大家如果有关于调试方面的问题，我乐意参与探讨。

作者：Simon Tatham 专业的自由软件程序员

翻译：Dasn

[ English | 简体中文 | Česky | Dansk | Deutsch | Français | Polski | Русский | 繁體中文 ]

引言

为公众写过软件的人，大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵——译者注）报告，例如：

在报告中说“不好用”；

所报告内容毫无意义；

在报告中用户没有提供足够的信息；

在报告中提供了错误信息；

所报告的问题是由于用户的过失而产生的；

所报告的问题是由于其他程序的错误而产生的；

所报告的问题是由于网络错误而产生的；

这便是为什么“技术支持”被认为是一件可怕的工作，因为有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌：我在业余时间维护自由软件，有时我会收到非常清晰、有帮助并且“有内容”的bug报告。

在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文，当然我也希望用户在给我报告bug之前已经读过这篇文章。

简单地说，报告bug的目的是为了让程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。如果愿意的话，您可以省去推测，但是千万别省略事实。

当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。除此以外，请记住：如果是免费软件，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。

“程序不好用”

程序员不是弱智：如果程序一点都不好用，他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。他们需要信息，报告bug也是为了提供信息。信息总是越多越好。

许多程序，特别是自由软件，会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了，那就不必再报告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。

本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。

如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。

“演示给我看”

报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。

他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。

这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题，他们通常会找到原因并开始试着修改。

“告诉我该怎么做”

如今是网络时代，是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里，当然他也可以用同样简单的方法给我一些建议。但是如果我的程序出了什么问题，我不可能在他旁边。“演示”是很好的办法，但是常常做不到。

如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。

确切地告诉程序员您做了些什么。如果是一个图形界面程序，告诉他们您按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。

把您能想到的所有的输入方式都告诉程序员，如果程序要读取一个文件，您可能需要发一个文件的拷贝给他们。如果程序需要通过网络与另一台电脑通讯，您或许不能把那台电脑复制过去，但至少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。

“哪儿出错了？在我看来一切正常哦！”

如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。

同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。

如果您看到了错误消息，一定要仔细、准确的告诉程序员，这确实很重要。在这种情况下，程序员只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来。

特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。不要以为您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。

在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，保存好。

如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。内核输出是特别有用的线索来源，别扔了它们。另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发邮件之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。

“出了问题之后，我做了……”

当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件，在找人帮忙之前她重装了Word，又运行了一遍碎片整理程序，这些操作对于恢复文件是毫无益处的，因为这些操作搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。如果她不做任何操作，或许还有一线希望。

这种用户仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物——译者注）：背靠墙壁，面对死亡的降临奋起反扑，疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。

不要做鼬，做一只羚羊。当一只羚羊面对料想不到的情况或受到惊吓时，它会一动不动，是为了不吸引任何注意，与此同时也在思考解决问题的最好办法（如果羚羊有一条技术支持热线，此时占线。）。然后，一旦它找到了最安全的行动方案，它便去做。

当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，快乐的程序员可以更快而且更有效率的修复bug。

“我想粒子的跃迁与错误的极化有关”

并不只是非专业的用户才会写出拙劣的bug报告，我见过一些非常差的bug报告出自程序员之手，有些还是非常优秀的程序员。

有一次我与另一个程序员一起工作，他一直在找代码中的bug，他常常遇到一个bug，但是不会解决，于是就叫我帮忙。“出什么毛病了？”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确，那的确是一件好事。这意味着他已经完成了工作的一半，并且我们可以一起完成另一半工作。这是有效率并有用的。

但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误，而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫，我得了Hydroyoyodyne（真是怪病——译者），给我开个方子”，人们知道不该对一位医生说这些。您描述一下症状，哪个地方不舒服，哪里疼、起皮疹、发烧……让医生诊断您得了什么病，应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了，这似乎没什么不对。

做程序员也是一样。即便您自己的“诊断”有时真的有帮助，也要只说“症状”。“诊断”是可说可不说的，但是“症状”一定要说。同样，在bug报告里面附上一份针对bug而做出修改的源代码是有用处的，但它并不能替代bug报告本身。

如果程序员向您询问额外的信息，千万别应付。曾经有一个人向我报告bug，我让他试一个命令，我知道这个命令不好用，但我是要看看程序会返回一个什么错误（这是很重要的线索）。但是这位老兄根本就没试，他在回复中说“那肯定不好用”，于是我又花了好些时间才说服他试了一下那个命令。

用户多动动脑筋对程序员的工作是有帮助的。即使您的推断是错误的，程序员也应该感谢您，至少您想去帮助他们，使他们的工作变的更简单。不过千万别忘了报告“症状”，否则只会使事情变得更糟。

“真是奇怪，刚才还不好用，怎么现在又好了？”

“间歇性错误”着实让程序员发愁。相比之下，进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作，观察每一个细节。太多的问题在这种情况下不能解决，例如：程序每星期出一次错，或者偶然出一次错，或者在程序员面前从不出错（程序员一离开就出错。——译者）。当然还有就是程序的截止日期到了，那肯定要出错。

大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的，有一些可能是别的程序在不恰当的时候修改某个重要文件造成的，还有一些可能发生在每一个小时的前半个小时中（我确实遇到过这种事情）。

同样，如果您能使bug重现，而程序员不能，那很有可能是他们的计算机和您的计算机在某些地方是不同的，这种不同引起了问题。我曾写过一个程序，它的窗口可以蜷缩成一个小球呆在屏幕的左上角，它在别的计算机上只能在 800x600 的解析度工作，但是在我的机器上却可以在 1024x768 下工作。

程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试，多试几次，两次，三次，看看问题是不是经常发生。如果问题出现在您进行了一系列操作之后，不是您想让它出现它就会出现，这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候，您要尽可能的记住您都做了些什么，并且如果您看到任何图形,也别忘了提一下。您提供的任何事情都是有帮助的。即使只是概括性的描述（例如：当后台有EMACS运行时，程序常常出错），这虽然不能提供导致问题的直接线索，但是可能帮助程序员重现问题。

最重要的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢，还是一个在另一类特定的计算机上才出现的错误。他们想知道有关您计算机的许多细节，以便了解您的机器与他们的有什么不同。有许多细节都依仗特定的程序，但是有一件东西您一定要提供——版本号。程序的版本、操作系统的版本以及与问题有关的程序的版本。

“我把磁盘装进了 Windows……”

表意清楚在一份bug报告里是最基本的要求。如果程序员不知道您说的是什么意思，那您就跟没说一样。我收到的bug报告来自世界各地，有许多是来自非英语国家，他们通常为自己的英文不好而表示歉意。总的来说，这些用户发来的bug报告通常是清晰而且有用的。几乎所有不清晰的bug报告都是来自母语是英语的人，他们总是以为只要自己随便说说，程序员就能明白。

• 精确。如果做相同的事情有两种方法，请说明您用的是哪一种。例如：“我选择了‘载入’”，可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”，说清楚您用了哪种方法，有时候这也有关系。
• 详细。信息宁多毋少！如果您说了很多，程序员可以略去一部分，可是如果您说的太少，他们就不得不回过头再去问您一些问题。有一次我收到了一份bug报告只有一句话，每一次我问他更多事情时，他每次的回复都是一句话，于是我花了几个星期的时间才得到了有用的信息。
• 慎用代词。诸如“它”，“窗体”这些词，当它们指代不清晰的时候不要用。来看看这句话：“我运行了FooApp，它弹出一个警告窗口，我试着关掉它，它就崩溃了。”这种表述并不清晰，用户究竟关掉了哪个窗口？是警告窗口还是整个FooApp程序？您可以这样说，“我运行FooApp程序时弹出一个警告窗口，我试着关闭警告窗口，FooApp崩溃了。”这样虽然罗嗦点，但是很清晰不容易产生误解。
• 检查。重新读一遍您写的bug报告，您觉得它是否清晰？如果您列出了一系列能导致程序出错的操作，那么照着做一遍，看看您是不是漏写了一步。

小结：

• bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。
• 如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来，尤其是“错误消息号”。
• 当您的计算机做了什么您料想不到的事，不要动！在您平静下来之前什么都别做。不要做您认为不安全的事。
• 尽量试着自己“诊断”程序出错的原因（如果您认为自己可以的话）。即使做出了“诊断”，您仍然应该报告“症状”。
• 如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号，它很可能是必需品。
• 表述清楚，确保您的意思不能被曲解。
• 总的来说，最重要的是要做到精确。程序员喜欢精确。