iOS异常处理

尽管当iphone应用崩溃时，它不会告诉用户发生了什么，但我们仍然可以为应用添加异常和信号处理，以此记录和展示发生的变化。更进一步，我们甚至能在异常发生时，阻止应用的崩溃。

引言

本文所用应用将抛出指定的Object-C异常，如EXC_BAD_ACCESS异常和响应的BSD signal。经过处理后，所有的异常和信号都会被捕获，然后展示调试信息，最后应用还能继续运行。

异常处理界面

上图应用会在4秒后故意触发一个未处理消息异常，并在10秒后触发 EXC_BAD_ACCESS/SIGBUS信号。

iPhone应用崩溃原因

崩溃（准确的说是程序异常终止）是程序接收到未处理信号的结果。

未处理信号有三个来源：内核、其他进程和应用本身。导致崩溃最常见的两个信号如下：

• EXC_BAD_ACCESS是一种由内核发出的Mach异常，通常是因为应用试图访问不存在的内存空间导致的。如果未能在Mach内核级别进行处理，它将被转化为SIGBUS或者SIGSEGVBSD信号。
• SIGABRT是当产生未捕获的NSException或者obj_exception_throw时，应用发给自身的BSD信号。

在Object-C异常中，导致异常抛出最常见的原因是应用向对象发送了未实现的方法选择器（比如拼写错误，对象混淆或者向已经释放的对象发送消息）。

捕获未捕获异常（uncaught exceptions）

正确处理未捕获异常的方式是在代码中修复异常产生的原因。如果你的程序工作良好，那么下面讲述的方法也就不重要了。

当然，有些bug也不一定总会导致应用崩溃。此外，当你的程序中出现bug时，你会希望测试人员能够返回一些有用的信息。

在这些情况下，有两种方式可以捕获那些会导致崩溃的未捕获状态。

• 使用NSUncaughtExceptionHandler函数来安装未捕获Object-C异常的处理器。
• 使用signal函数来安装BSD信号处理器。

例如，安装Object-C异常处理器和信号处理的代码如下：
objc
void InstallUncaughtExceptionHandler()
{
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
}
objc
对于异常和信号的响应会在HandleException和SignalHandler中实现。在样例程序中，以上二者的处理方式相同。

尽管本文只处理最常见的信号，但是，你可以为自己的程序添加所需的所有异常信号。

注意，有两种异常是不能捕获的：SIGKILL和SIGSTOP。它们会终止或者暂停应用。（SIGKILL是命令行函数kill -9发出的，SIGSTOP是键入Control-Z发出的）。

异常处理的要求

未处理异常处理器可能永远不能返回

导致未处理异常或信号处理器被触发的场景通常都是应用中不可逆的场景。

然而，有时仅是栈帧或者当前函数不能恢复。如果你能阻止当前栈帧继续执行，那么剩下的程序还可能继续执行。

如果你想尝试这种情况，那么你的未处理异常处理器必须不将控制权返回给正在调用的函数——产生异常或者触发信号的代码不允许被再次使用。

为了在不返回控制权给调用函数的情况下，继续执行代码，我们必须返回主线程（假设我们现在不在主线程），并永久阻塞旧线程。同时，在主线程中，我们必须开启新的run loop，且不在返回原来的run loop。

这意味着被导致异常的线程所使用的栈内存将永远泄漏。这就是代价。

尝试恢复

由于新的run loop将用来显示会话，它将保持无限运行，同时，它还可以取代应用的主run loop。

为此，该run loop必须能够处理主线程的所有模式。由于主run loop包含了许多私有模式（如GSEvent处理和滑动跟踪），默认的NSDefaultRunLoopMode是不够的。

幸运的是，如果UIApplication已经创造了主loop的所有模式，那么，就可以从该loop中读取所有这些模式。假设这些代码在main loop创建后运行在主线程，那么它也能在所有的UIApplication模式下运行循环：
objc
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);

while (!dismissed)
{
for (NSString *mode in (NSArray *)allModes)
{
CFRunLoopRunInMode((CFStringRef)mode, 0.001, false);
}
}

CFRelease(allModes);
objc

作为调试信息的一部分，我们需要获取栈地址

你可以使用backtrace函数来取得回溯信息，并使用backtrace_symbols来将它们转化为标记。
objc

• (NSArray )backtrace
  {
  void callstack[128];
  int frames = backtrace(callstack, 128);
  char **strs = backtrace_symbols(callstack, frames);

  int i;
  NSMutableArray *backtrace = [NSMutableArray arrayWithCapacity:frames];
  for (
  i = UncaughtExceptionHandlerSkipAddressCount;
  i < UncaughtExceptionHandlerSkipAddressCount + UncaughtExceptionHandlerReportAddressCount;
  i++)
  {
  [backtrace addObject:[NSString stringWithUTF8String:strs[i]]];
  }
  free(strs);
  return backtrace;
  }
  objc
  注意，我们跳过了开始的一些地址：这是因为它们是信号和异常处理函数的地址（不重要）。由于我们想要保存最少的数据（用于在UIAlert对话框显示），我选择放弃显示异常处理函数。

如果用户选择“退出”，我们将会记录崩溃日志

如果用户选择“退出”来终止应用，而不是继续运行程序，用常用的崩溃日志处理来记录记录问题不失为一个好方法。

在本例中，我们将移除所有的异常处理器，并再次生成异常或者重新发送信号来使得程序像往常一样崩溃（尽管未处理异常处理器会出现在栈的顶部，但后面的帧是相同的）。