《编写高质量iOS与OS X代码的52个有效方法》--第五章 第32条
（ps：此乃读书笔记，加深记忆，仅供大家参考）
第32条 编写“异常安全代码”时留意内存管理问题
许多时下流行的编程语言都提供了“异常”（exception）这一特性。纯C中没有异常，而C++与Objective-C都支持异常。实际上，在当前的运行期系统中，C++与Objective-C的异常相互兼容，也就是说，从其中一门语言里抛出的异常能用另外一门语言所编的“异常处理程序”（exception handler）来捕获。
发生异常时应该如何管理内存是个值得研究的问题。在try块中，如果先保留了某个对象，然后在释放它之前又抛出了异常，那么除非catch块能处理此问题，否则对象所占内存就将泄露。C++的析构函数（destructor）由Objective-C的异常处理例程（exception-handle routine）来运行。这对于C++对象很重要，由于抛出异常会缩短其生命期，所以发生异常时必须析构，不然就会泄露，而文件句柄（file handle）等系统资源因为没有正确清理，所以就更容易因此而泄露了。
异常处理例程将自动销毁对象，然而在手动管理引用计数时，销毁工作有些麻烦。
EOCPerson * object;
@try {
object = [[EOCPerson alloc] init];
[object doSonethingThatMayTHrow];
} @catch (NSException *exception) {
NSLog(@"Whoops, there was an error. Oh well...");
} @finally {
[object release];
}
在ARC环境下，问题会更严重。
@try {
EOCPerson * object = [[EOCPerson alloc] init];
[object doSonethingThatMayTHrow];
} @catch (NSException *exception) {
NSLog(@"Whoops, there was an error. Oh well...");
}
由于不能调用release，所以无法像手动管理引用计数那样把释放操作移到@finally块中。你可能认为这种状况ARC会自动处理的。但实际上ARC不会自动处理，因为这样做需要加入大量样板代码，以便跟踪待清理的对象，从而在抛出异常时将其释放。可是，这段代码会严重影响运行期的性能，即便在不抛出异常时也是如此。
虽说默认状况下未开启，但ARC依然能生成这种安全处理异常所用的附加代码。-fobjc-arc-exceptions这个编译器标志用来开启此功能。其默认不开启的原因是：在Objective-C代码中，只有当应用程序必须因异常状况而终止时CIA抛出异常。
有种情况编译器会自动把-fobjc-arc-exceptions标志打开，就是出于Objective-C++模式时。
要点
- 捕获异常是，一定要注意将try块内所创立的对象清理干净。
- 在默认情况下，ARC不生成安全处理异常所需的清理代码。开启编译器标志后，可以生成这种代码，不过会导致应用程序变大，而且会降低运行效率。
