以下是最简单的代码写法,其中@finally可以去掉:
@try {
// 可能会出现崩溃的代码
}
@catch (NSException *exception) {
// 捕获到的异常exception
}
@finally {
// 结果处理
}
在这里举多一具比较详细的方法,抛出异常:
@try {
// 1
[self tryTwo];
}
@catch (NSException *exception) {
// 2
NSLog(@"%s\n%@", __FUNCTION__, exception);
// @throw exception; // 这里不能再抛异常
}
@finally {
// 3
NSLog(@"我一定会执行");
}
// 4
// 这里一定会执行
NSLog(@"try");
tryTwo方法代码:
- (void)tryTwo
{
@try {
// 5
NSString *str = @"abc";
[str substringFromIndex:111]; // 程序到这里会崩
}
@catch (NSException *exception) {
// 6
// @throw exception; // 抛出异常,即由上一级处理
// 7
NSLog(@"%s\n%@", __FUNCTION__, exception);
}
@finally {
// 8
NSLog(@"tryTwo - 我一定会执行");
}
// 9
// 如果抛出异常,那么这段代码则不会执行
NSLog(@"如果这里抛出异常,那么这段代码则不会执行");
}
为了方便大家理解,我在这里再说明一下情况:
如果6抛出异常,那么执行顺序为:1->5->6->8->3->4
如果6没抛出异常,那么执行顺序为:1->5->7->8->9->3->4
2)部分情况的崩溃我们是无法避免的,就算是QQ也会有崩溃的时候。因此我们可以在程序崩溃之前做一些“动作”(收集错误信息),以下例子是把捕获到的异常发送至开发者的邮箱。
AppDelegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
return YES;
}
void UncaughtExceptionHandler(NSException *exception) {
/**
* 获取异常崩溃信息
*/
NSArray *callStack = [exception callStackSymbols];
NSString *reason = [exception reason];
NSString *name = [exception name];
NSString *content = [NSString stringWithFormat:@"========异常错误报告========\nname:%@\nreason:\n%@\ncallStackSymbols:\n%@",name,reason,[callStack componentsJoinedByString:@"\n"]];
/**
* 把异常崩溃信息发送至开发者邮件
*/
NSMutableString *mailUrl = [NSMutableString string];
[mailUrl appendString:@"mailto:[email protected]"];
[mailUrl appendString:@"?subject=程序异常崩溃,请配合发送异常报告,谢谢合作!"];
[mailUrl appendFormat:@"&body=%@", content];
// 打开地址
NSString *mailPath = [mailUrl stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:mailPath]];
}
详细解释下
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:@"[email protected]",..., nil];
//构造Mail URL,也可以做成弹出框等其他方式保存或者展示提示信息
NSString *urlStr = [NSString stringWithFormat:@"mailto:%@?subject=Megafon-HD Bug Report &body=Thanks for your coorperation!
"
"AppName:SomeAPP
"\
"Version:%@
"\
"Build:%@
"\
"Detail:
%@
--------------------------
%@
---------------------
%@",
APPVersionName,APPBulidName,nameArray,
name,reason,[arr componentsJoinedByString:@"
"]];
//调用系统能力 发送邮件
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]"等。