错误处理和调试

程序出错可以分为两大类：编译时错误（complie-time error）和运行时错误（run-time error）。

编译时错误：

相比之下，编译时错误显然是比较轻的。因为编译将会告诉你它发现了什么错误和它是在哪行代码发现了这个错误的。我们需要做的只是认真观察和分析编译器给出的出错信息，然后按语法要求改正即可。下边总结一些编程好经验给大家参考：

建议一：培养并保持一种编程风格！第一个建议是在编程的时候保持一种风格，一旦决定了要如何命名变量和函数、要按何种格式编写代码、如何缩进代码块等，就应该一直保持下去。请参考编程风格规范参考章节。
建议二：认真对待编译器给出的错误/警告信息！有时候，编译器给出的警告信息完全没道理，但大多数时候还是很有用的，虽然警告不影响程序编译，但千万不要忽视它们。
建议三：三思而后行！开始写代码前先画流程图。编译错误不要立刻修改源代码，应该先完整地审阅一遍源代码，再开始纠正错误。因为冒失地修改源代码往往会造成错误越改越多、心情越改越乱的纠结局面。
建议四：注意检查最基本的语法! 再有经验的妞也会上钩，再有经验的程序员也同样会犯一些小错误。
建议五：把可能有问题的代码行改为注释! 不要轻易整行整行地删除代码，把可能有问题的代码行先改成注释，看错误是否还在。排除法。。。
建议六：换一个环境或开发工具试试! 一般来说，编译器不会有问题，但如果你始终无法确定问题出在哪里，不妨换一下编译器或者操作系统，常常有时候弱智的杀软会阻止编译器导致编译器犯傻。
建议七：检查自己是否已经把所有必要的头文件全部 include 进来。例如只有 #include <iostream> 才能使用 cout，与此相类似的情况成百上千，并容易忽略，注意调用不熟悉的函数前查看相关文档，确定该函数需要哪些头文件支持。
建议八：留意变量的作用域和命名空间! 程序代码对变量的访问权限可能导致各种各样的问题，这个知识今后我们会深入探讨。
建议九：休息一下！在情绪变得越来越焦躁的时候，你发现和解决问题的能力会直线下降。这时候应该让自己放松一下，离开计算机，等头脑清醒了再回来解决问题。做开发的时候也是同样哦 ^_^
建议十：使用调试工具绝大多数 IDE 都有一个内建的调试器，一定要学习使用它并经常使用它。
最后，避免错误的另一个好方法就是把调试好的代码另外保存起来并不再改动它。然后把代码划分成各个模块，用它们（在你能保证它们都没有问题的情况下）来搭建新的应用程序，会让你减少很多开发和调试的时间。

运行时错误：

运行时错误往往远比编译时错误更难以查找和纠正，运行时错误一般都不会有正式的出错信息。它们的发生几率因不同程序思路不同而不同，很少有规律可循。更多的情况是时有时无，有的程序在这台计算机上很正常，在另一台计算机上就总是出问题。或者，某几个用户经常遇到这样或那样的问题，其他用户却都正常。运行时错误的外在表现可以说是千变万化！

经验一：还是培养并保持一种良好的编程风格！杂乱无章是程序员最大的敌人，找到你最喜欢的编程风格然后一直保持下去吧！
经验二：多用注释，用好注释。如果忘记了某段代码的用途和理由，再想回来调试修改这段代码可就费劲了。这里要注意的是，必须让注释和代码保持同步，一旦修改了代码，就应该对注释进行相应的修改。注意不要做无谓的注释。
经验三：注意操作符的优先级操作符的优先级决定着有关操作的发生顺序，如果想让一系列操作按照希望的顺序发生，最保险的方法是用括号来确保这种顺序。此处应该有例子：example.cpp
```
#include <iostream>

int main()
{
    int a = 1, b;

    if( b = a-- )//目标:此处将a的值-1赋值给b，实现不了！必须改成b=(a--)
    {
        std::cout << "Yeah!
";
    }
    else
    {
        std::cout << "Out!
";
    }

    return 0;
}
```
另外，不要对操作顺序做任何假设 —— 在某些场合，++，* 和 -> 之类的高优先级操作符的行为也不见得是你想象那样哦。
经验四：千万不要忘记对用户输入和文件输入进行合法性检查!如果让某个程序员去调试他本人编写的代码，他往往不能把所有的漏洞全都找出来 —— 因为他会下意识地避免各种不正常的做法。只有用户才会做出一些出乎意料的事情，对于来自用户的输入，一定要采用正确的方法来读取它们和检查它们的合法性，确保你将要处理的数据符合你对它们的要求。恩恩，千万不要想当然哦~
经验五：不要做任何假设! 这是一句老生常谈了，但至今仍适用于所有场合。不要想当然地认为一个应该发生的操作比如打开一个文件、创建一个新的内存块，等等。不要想当然地认为用户肯定会按照你的意愿去使用你的程序。
经验六：把程序划分成一些比较小的单元模块来测试! 程序越长，就越难以测试，只要条件允许，就应该把一个比较大的程序划分成一系列比较小的单元模块来分别加以测试。