Objective-c 初阶——异常处理（try-catch）

一、@try/@catch/@throw/@finally 执行顺序

void doSomething() { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; @try { // 这一步抛异常 [self riskyMethod]; } @catch (NSException *e) { @throw; // 把异常继续往上抛 } @finally { // ❗ 注意：这里的 finally 会 **立刻执行** [pool release]; // 🔥🔥🔥 外层 pool 提前 pop 了 } // ❌ 如果你此时还没处理完那个 exception，它里面的对象已经被释放了}1. riskyMethod 抛出异常2. 进入 @catch 块3. @catch 里调用了 @throw（重新抛出）4. ❗ 根据编译器实现，@finally 会 **立刻执行** ⬅️ 在这个“再抛之前”，@finally 就执行了5. @finally 执行时，释放了 autorelease pool6. ❌ 异常对象（NSException 实例）可能在 autorelease pool 中，它被提前释放了7. 异常还没被真正交到上层 catch，就已经是 zombie 了

二、try-catch 内存管理（坑）

1、普通内存泄漏

1.1. 如何泄漏

- (void)doSomething { NSMutableArray *anArray = [[NSMutableArray alloc] initWithCapacity:0]; @try { [self doSomethingElse:anArray]; // 假设一定会抛错 } @catch(...) { @throw; } [anArray release];}

就像这种情况，我在 catch 里又重新抛异常，那么就会导致 [anArray release]; 就不会被执行了，所以 anArray 就会内存泄漏了。

1.2. 解决方案

- (void)doSomething { NSMutableArray *anArray = [[NSMutableArray alloc] initWithCapacity:0]; @try { [self doSomethingElse:anArray]; // 假设一定会抛错 } @catch(...) { @throw; } @finally { [anArray release]; }}

2、提前释放 auto release pool 引起的内存泄漏

2.1. 如何泄漏

- (void)doSomething { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSException *ex = [NSException exceptionWithName:@\"MyError\" reason:nil userInfo:nil]; // 创建 NSException，retain 一次，retainCount + 1 @throw ex; // 由 runtime retain 1 次，retainCount + 2 [pool release]; // 不会执行}@try { [someObject doSomething]; // 抛出 ex} @catch (NSException *e) { @throw; // 再次抛出 ex，但这是 rethrow, retainCount 不会加 1} @finally { [outerPool release]; // 释放 ex 所在 autorelease pool，retainCount - 1; // 因为 ex 是通过 unwind 找到当前栈帧的，且当前栈帧有 @finally, // 所以会调一次 runtime cleanup 来清理对象，retainCount - 1; // 此时 ex 的 retainCount 为 0，ex 被 dealloc}

因为 doSomething: 函数内部创建了一个 auto release pool；而且外层又有一个 auto release pool，所以这两个 auto release pool 是这样的：

然后 ex 的引用计数看注释就可以了。顺带提一下，只要是被 unwind 到当前栈帧且当前栈帧有 @finally，系统就会在 finally 块里调 cleanup 函数，给当前所有对象的 retain count 减 1.

那什么时候会被 unwind 呢？其实就是当异常对象被 throw 或当前函数栈帧无法捕获异常时，系统就会调unwind 来一个个函数栈帧往上找。只要当前栈帧（没有 throw 的栈帧）的 catch 能捕获到异常且 catch 不再重新抛出异常，unwind 就不会继续被调。

 2.2. 解决方案

- (void)doSomething { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSException *ex = [NSException exceptionWithName:@\"MyError\" reason:nil userInfo:nil]; @throw ex; [pool release]; // 不会执行}@try { [someObject doSomething]; // 抛出 ex} @catch (NSException *e) { [e retain]; @throw; } @finally { [outerPool release]; }

是的，就是给 e 的 retainCount 多加 1 就可以了。这样就可以给整个异常对象的引用计数加 1，不让他被 dealloc 掉。 

三、性能对比：32 位的 try-catch VS 64 位的 try-catch

先提前下个结论：根据苹果开发者文档，其实 32 位跟 64 位的 try-catch 各有利弊。因为苹果针对  64 位情况重新实现了 objective-c 的异常处理机制，也就是说采用了 cpp 的 zero-cost 的异常处理机制；因此，32 位的 try-catch 在 try 的部份性能比 64 位的 try 部份差；而 64 位的 throw 部份会比 32 位的 throw 部份差。下面我会分别讲这两部分性能差异的原理。不过先叠个甲，里面的伪代码实现都是用于逻辑自洽的，语法上难免会有错误。

1、32 位下 objective-c 的异常处理机制

其实在 32 位下 objective-c 的异常处理机制是这样的：每进入一个 @try 块，都会先创建一个异常栈帧（不是函数的栈帧），把当前 @try 代码块的地址写到 jmp_buf env 里，然后再调 setjmp 函数来标记 longjmp() 应该跳到的地方。

对于每一个 throw 函数，都会调 longjmp() 函数，然后让程序的 pc 指针指向当前异常栈帧的 setjmp(frame.env) 处。因为 setjmp(frame.env) 此时返回值不是 0，所以跳到 catch 执行……然后一直沿着 try 的调用链往上找 catch。

typedef struct ExceptionFrame { jmp_buf env; struct ExceptionFrame *prev; const char *handledType; // 这个 try 块能处理的异常类型 Exception *caughtException; // 用于传值给 catch} ExceptionFrame;__thread ExceptionFrame *topFrame = NULL; // 每个线程一份

// try 的伪代码实现#define TRY(type) do { \\ ExceptionFrame frame; \\ frame.prev = topFrame; \\ frame.handledType = type; \\ frame.caughtException = NULL; \\ topFrame = &frame; \\ if (setjmp(frame.env) == 0)#define CATCH(x) else for (Exception *x = frame.caughtException; x != NULL; x = NULL)#define END_TRY \\ topFrame = frame.prev; \\} while (0)// throw 的伪代码实现#define THROW(e) do { \\ currentException = e; \\ ExceptionFrame *frame = topFrame; \\ while (frame) { \\ if (strcmp(frame->handledType, e->type) == 0 || strcmp(frame->handledType, \"*\") == 0) { \\ frame->caughtException = e; \\ topFrame = frame->prev; \\ longjmp(frame->env, 1); \\ } \\ frame = frame->prev; \\ } \\ fprintf(stderr, \"Uncaught exception: %s\\n\", e->message); \\ abort(); \\} while (0)

TRY { // 这里写 try 块的内容 maybeDangerousFunction(); THROW(&someException);} CATCH(e) {} END_TRY;

2、64 位下 objective-c 的异常处理机制

但是在 64 位下 objective-c 的异常处理用的是 zero-cost 那套，也就是每进入一个 try 块时并不会创建一个 exception frame。但一旦遇到 throw 时，就会从当前函数栈帧开始，找每个栈帧的匹配的 catch 块，找不到就再去上一个函数栈帧找。

struct StackFrame { StackFrame *prev; // 栈上的上一个帧 FunctionMeta *functionMeta; // 指向 LSDA + handler 信息 void *pc;  // 当前执行地址 (程序计数器)};struct Exception { const char *type; const char *message;};typedef struct { char *type;  // 异常类型 void (*handler)(Exception*); // catch handler 跳转landing pad void (*cleanup)(void); // cleanup handler，例如 finally int hasCleanup;  // 是否有 cleanup} CatchClause;struct FunctionMeta { CatchClause *clauses; // 存 catch 代码块地址的数组，一个 catch 对应一个 clause int clauseCount; void (*personality)(StackFrame *, Exception *);};

// 默认的 personality 函数，带 cleanup 处理void defaultPersonality(StackFrame *frame, Exception *e) { int handled = 0; // 该层栈帧的 catch 能否捕获异常，可以为 1，不可以为 0 // 先查找 catch clause for (int i = 0; i functionMeta->clauseCount; ++i) { CatchClause *clause = &frame->functionMeta->clauses[i]; if (strcmp(clause->type, e->type) == 0) { // 找到匹配的 catch clause->handler(e); // 执行 catch handler（landing pad） handled = 1; break; } } // 调用 cleanup handler（无论 catch 是否找到都会调用 cleanup） for (int i = 0; i functionMeta->clauseCount; ++i) { CatchClause *clause = &frame->functionMeta->clauses[i]; if (clause->hasCleanup && clause->cleanup != nullptr) { clause->cleanup(); // 执行 cleanup，比如 finally } } if (!handled) { // 当前栈帧不能处理异常，继续向上 unwind unwind(frame->prev, e); }}// throw 异常时当前栈帧直接调 unwind，可以看成 defaultPersonality 是私有的void unwind(StackFrame *frame, Exception *e) { if (!frame) { printf(\"Uncaught exception: %s\\n\", e->message); abort(); } frame->functionMeta->personality(frame, e);}

unwind 执行什么呢？就是先看看当前栈帧有没有符合类型的 catch 可以捕获异常；然后在看看当前栈帧有没有 finally，有的话就调 cleanup()；然后如果当前栈帧可以捕获异常，不继续调 unwind ，否则继续调上一个栈帧的 unwind.

3、性能差异原因

所以 32 位下 oc 的 try 比 64 的 try 性能消耗更大是因为 32 位下 oc 会给每一个 try 块创建一个叫 jmp_buf env 的东西，而且还会调一次 setjmp() ；但 64 位对每一个 try 块并不会做任何事，所以 32 位下 try 块会比 64 位需要更多的内存。

那 64 位的 throw 比 32 位的 throw 性能更差是因为 32 位下用的是 exception frame + longjmp() 来跳转，每一跳肯定可以跳到最近有 catch 的函数栈帧中，所以 32 位找对应 catch 所花的时间是比 64 位一个一个栈帧找要快的。