程序员是要慢慢成长的，比如错误处理这种事情，就不是一开始就面对的。当我们编的程序还很小，小到“cin>>i; cout<<i;”这样的程度，错误处理不是我们要学习的目标。但是，一旦开始编写实用的程序，那么，无论考虑多么周到，无论代码多么精良。意外总是难免的。这些意外可能来自程序员的设计不到位、可能来自用户的错误操作、还可能来自机器与网络的不确定因素。
　　没有什么比追踪错误更难过的事了，记得有一回我在追踪一个VB程序的错误。经过长时间测试，我发现程序在运行中突然发生很大的跳跃：函数A调用B，B调用C，在C的执行过程中，居然会突然跳到A中。后来追查发现，原来A中有一行“On Error Goto”语句。这一个语句，影响了我调试C函数。从那以后，我明白了，除非程序要发布了，否则别启动错误处理。
　　C++与VB不一样，VB用一句“On Error Goto”启动了错误处理后，在该函数结束之前一直有效（除非显式地关闭它）。如果发生了异常，处理代码要根据异常的值来分析异常的类型。而C++可以选择可能出现异常的内容放进try后的块中。一个函数内部可以有多个try块，而每个try块又可以附带多个catch来处理。应该说，C++中的异常处理更灵活，当然也更容易出错。我前阵子发生的错误就是在ADO处理后只有“catch(_com_error *e)”，但是实际上出现的异常却不是“_com_error”类的，结果仍然抓不往异常。
　　异常处理和assert之间的关系有些让人难以捉摸。一方面它们各有各的作用，另一方面它们有时会互相影响。我就曾经在这上面吃过亏：我的程序是在服务器上运行的，从来没人会盯着服务器看，所以我的程序不允许弹出对话框。我写了比较完善的异常处理，无论出现什么错误，都记录进LOG文件，然后继续运行。但是我却是用DEBUG模式编译的，结果异常到来时，try没起作用，倒是assert起作用了，弹了个对话框在那儿。这件事给我的启发是：别以为自己是程序的客户就可以用DEBUG模式编译。