IOS学习笔记60--异常处理

好久好久没有写博客了，说实话吧，一个是因为忙，但更重要的是冬眠了，感觉，懒的写了。但是，这脑子吧，实在是不好使，记不住东西，所以，还是通过博客记录下，以后吧，一定要常常更新，算是给2013结一个好尾，给2014开一个好头了。今天吧，就说说异常处理，感觉这东西也是比较有用的，言归正传，咱接着谈异常。

Crash分为两种，一种是由EXC_BAD_ACCESS引起的，原因是访问了不属于本进程的内存地址，有可能是访问已被释放的内存；另外一种是未被捕获的Objective-C异常     (NSException)，导致程序向自身发送了SIGABRT信号而崩溃。

SIGABRT(也叫做EXC_CRASH)是一个比较好解决的Crash，因为他是一个可掌控的crash。App会在一个目的地终止，因为系统意识到app做了一些他不能支持的事情.

          EXC_BAD_ACCESS是一个比较难处理的crash了，当一个app进入一种毁坏的状态，通常是由于内存管理问题而引起的时，就会出现出现这样的crash。

         其实对于未捕获的Objective-C异常，我们是有办法将它记录下来的，如果日志记录得当，能够解决绝大部分崩溃的问题。

1.NSSetUncaughtExceptionHandler

        iOS SDK提供了NSSetUncaughtExceptionHandler函数,在UI线程发生未捕获异常后，进程崩溃之前，handleRootException会被执行。这样获取的崩溃信息，即使没有编译时生成的符号文件，也能够打印出调用栈上的每个函数的名称，只是没有文件名和行号。

       异常捕获函数:
void UncaughtExceptionHandler(NSException *exception) 
{
    //获取异常信息
    NSArray *arr = [exception callStackSymbols];
    NSString *reason = [exception reason];

    //接受异常信息的邮箱
    NSString *name = [exception name];
    NSArray *nameArray = [NSArray arrayWithObjects:@"[e-mail]",..., nil];

    //构造Mail URL，也可以做成弹出框等其他方式保存或者展示提示信息
    NSString *urlStr = [NSString stringWithFormat:@"mailto:%@?subject=Megafon-HD Bug Report &body=Thanks for your coorperation!<br><br><br>"
                        "AppName:SomeAPP<br>"\
                        "Version:%@<br>"\
                        "Build:%@<br>"\
                        "Detail:<br>%@<br>--------------------------<br>%@<br>---------------------<br>%@", 
                        APPVersionName,APPBulidName,nameArray,
                        name,reason,[arr componentsJoinedByString:@"<br>"]];

    //调用系统能力 发送邮件
    NSURL *url = [NSURL URLWithString:[urlStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
    [[UIApplication sharedApplication] openURL:url];
}

       函数调用 在APP启动时调用:

       NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);

2.@Try Catch
    @try {
       //Code… 存在问题的代码
    }
    @catch (NSException *exception) {
        //<1>断点 可以更清晰的看到一些调用信息 从而发现错误源
        //<2.1>日志(打印一些相关的信息 分析错误源)或者其他方式保存记录信息
        NSLog(@"%@",exception);
        //<2.2>也可以调用Exception处理方法
        [self UncaughtExceptionHandler:exception];
    }
    @finally {

    }
        简单的来说，Apple虽然同时提供了错误处理（NSError）和异常处理（exception）两种机制，但是Apple更加提倡开发者使用NSError来处理程序运行中可恢复的错误。而异常被推荐用来处理不可恢复的错误。
        原因有几个，在非gc情况下，exception容易造成内存管理问题（文档有描述即使是arc下，也不是安全的）；exception使用block造成额外的开销，效率较低等等，另外这也的确是Cocoa开发者的习惯。

3.环境变量

       菜单里Product->EditScheme->Run->Environment Variables, 添加NSZombieEnabled，并设置其值为YES。Zombie环境变量对于处理EXC_BAD_ACCESS类型崩溃很有效。

       当这个zombie工具被启用之后，即使这个对象被释放了，这个对象的内存也不会被清理。所以，那块内存将会被标记为“长生不死的”。假如你试着之后又去使用这块内存，这个app能够意识到你的错误操作，并且app将会抛出“message sent to daellocated instance”错误并且终止运行。
       你不应该一直启用zombie objects。因为这个工具将永远不会释放内存，只是简单标记一下这个内存是不死的，你最终将会在某个时候耗尽所有的内存。因此你应该在排查内存相关的错误的时候才开启zombie objects，其他时候应该关闭它。

4.崩溃断点

     Xcode 4为例:

     <1>在工程左侧的控制栏找到断点控制栏(Breakpoint Navigator)，选择它

     <2>点击左下角"+",选择"Add Exception BreakPoint..."

     <3>弹出框之后选择"Done"之后，断点控制栏就会多出一个断点：All Exceptions.

     设置完成之后，改断点可以再大部分崩溃发生之前，停留在崩溃代码行。方便查看崩溃信息。当程序崩溃时，如果断点启用，那么查看堆栈信息，被高亮的代码信息就是程序代码，而灰色的部分则是系统方法调用。

总结:

     1.注意编译警告，每一个编译警告都是一个潜在BUG，它总会在某种情况下发生错误。

     2.编译时自动静态编译设置：Build Settings ->Run Static Analyzer 设置为YES.会在工程编译时自动静态编译，提示你更多的从错误信息。

     3.编译器的一些命令:"po"是Print Object.,打印对象内容。"p"则是打印实际地址，而非对象。"c"是遇到断点时继续程序。"$eax"时CPU的一个寄存器，在异常情况下，这个寄存器会寄存一个异常指针，如果在异常时输入"po [$eax class]"会得到"$2 = ... NSException",它是一个异常类，这样就可以打印它的name,reason等信息了如"po [$eax name]"等。