合理的制造bug，及查找bug

一、合理的制造Crash BUG

什么是BUG，简单点说就是，程序没有按照我们预想的方式运行。我比较喜欢把BUG分成两类：

• 1、Crash掉的
• 2、没有Crash掉的

Crash不可怕，可怕的是程序没有Crash而是运行在一个不稳定的状态下，如果程序还操作了数据，那带来的危害将是灾难性的，因此尽量制造Crash的BUG，减少没有Crash的BUG，尽可能将没有Crash掉的Bug转换成Crash的BUG。

NSAssert可以将没有Crash掉的bug尽可能的转换为Crash的bug，他的名字叫做“断言”。断言（assertion）是指在开发期间使用的、让程序在运行时进行自检的代码（通常是一个子程序或宏）。断言为真，则表明程序运行正常，而断言为假，则意味着它已经在代码中发现了意料之外的错误。断言对于大型的复杂程序或可靠性要求极高的程序来说尤其有用。而当断言为假的时候，几乎所有的系统的处理策略都是，让程序死掉，即Crash掉。断言其实是“防御式编程”的常用的手段。防御式编程的主要思想是：子程序应该不因传入错误数据而被破坏，哪怕是由其他子程序产生的错误数据。这种思想是将可能出现的错误造成的影响控制在有限的范围内。断言能够有效的保证数据的正确性，防止因为脏数据让整个程序运行在不稳定的状态下面。

• 断言的使用场景(参考《代码大全2》中“防御式编程”一章，这里简单的做了一点摘录，概括其大意)：
• 用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。
• 避免把需要执行的代码放到断言中
• 用断言来注解并验证前条件和后条件
• 对于高健壮性的代码，应该先使用断言再处理错误
• 对来源于内部系统的可靠的数据使用断言，而不要对外部不可靠的数据使用断言，对于外部不可靠数据，应该使用错误处理代码。 而在IOS编程中，我们可以使用NSAssert来处理断言。

每一个线程都有它自己的断言捕获器（一个NSAssertionHanlder的实例），当断言发生时，捕获器会打印断言信息和当前的类名、方法名等信息。然后抛出一个NSInternalInconsistencyException异常让整个程序Crash掉。并且在当前线程的断言捕获器中执行handleFailureInMethod:object:file:lineNumber:description:以上述信息为输出。

当时，当程序发布的时候，不能把断言带入安装包，你不想让程序在用户机器上Crash掉吧。打开和关闭断言可以在项目设置中设置assert ,在release版本中设置了NS_BLOCK_ASSERTIONS之后断言失效。

二、尽可能不要用Try-Catch

并不是说Try-Catch这样的异常处理机制不好。而是，很多人在编程中，错误了使用了Try-Catch，把异常处理机制用在了核心逻辑中。把其当成了一个变种的GOTO使用。把大量的逻辑写在了Catch中，这种情况干嘛不用if else呢。实际上，异常处理只是用户处理软件中出现异常的情况。常用的情况是子程序抛出错误，让上层调用者知道，子程序发生了错误，并让调用者使用合适的策略来处理异常。一般情况下，对于异常的处理策略就是Crash，让程序死掉，并且打印出堆栈信息。而在IOS编程中，抛出错误的方式，往往采用更直接的方式。如果上层需要知道错误信息，一半会传入一个NSError的指针的指针

三、如何查找bug发生的原因

于是解决BUG一般可以分两步进行：

• 合理性假设，找到可能性最高的一系列原因。
• 对上面找到的原因与BUG之间的因果性进行分析。

这篇文章是在别人的基础上做的一些整理，原文章出处为：http://www.cocoachina.com/ios/20160229/14251.html