iOS 错误处理（一）

最新推荐文章于 2020-02-20 01:21:31 发布

王冠卿

最新推荐文章于 2020-02-20 01:21:31 发布

阅读量1.4k

点赞数

分类专栏： iOS应用开发文章标签： iOS 错误调试应用安全

本文链接：https://blog.csdn.net/u011553971/article/details/9630725

版权

iOS应用开发专栏收录该内容

3 篇文章 0 订阅

订阅专栏

错误处理恐怕是开发过程中最让人难受的环节之一。在正常情况下让程序的各部分都正常工作已经是比较困难的了，一个好的应用应该在出错时也有得体的表现。

1. 错误处理模式

三种模式

1.1预期错误

磁盘空间不足是一种预期错误，虽然它极少发生，iTunes在用户设备中装满了音乐文件，这种情况很容易发生。当无法写入文件时，需要能够优雅的恢复

对于那些会预期发生的错误，应该得体的进行处理，不应该让程序崩溃。处理这种错误，比较通用的方式是返回一个NSError对象的引用

1.2程序错误

-(void)doSomething:(NSUInteger)index

{

if (index> self.maxIndex)

{

return;

}

传入一个超出有效范围的索引值是一种编程错误，这段代码默默忍受了这种错误，没有做出任何操作。这种问题非常难于调试。应该传入有效的值，这是方法调用者的责任。默默忽略错误值是NSArray能做的最糟糕的事情，让程序崩溃会是一个更好的选择

1.3非预期错误

在iOS中，分配小块内存失败是一种非预期错误，在正常操作中永远不该发生。在遇到这个错误之前，程序应该早就收到内存预警消息并且被强制结束了。

NSString * string =[NSString stringWithFormat:@"%d",1];

NSArray * array = [NSArray arrayWithObject:string];

由于Foundation无法正确分配内存而导致stringWithFormat：方法失败，这种情况是可能发生的。这样会导致程序会抛出一个”试图向数组中插入nil”的异常，最后很可能导致应用崩溃。C语言编程一般会加一个检查来防止这种情况发生，iOS不需要这样。

通常情况下可以忽略非预期错误，直接让程序崩溃就好了。理由：发生概率极小；保持代码简洁；OC中为内存分配错误处理代码几乎是没有意义。

2. 断言

使用断言可以有效的防止程序错误。断言要求程序中特定的语句必须为真。如果不为真，说明程序正处于一种无法预测的状态，这时候程序不应该继续执行下去。

NSAssert( index != 0 , @"indexmust not be zero");

[self doSomething:0];

控制台打印：

2013-07-13 10:31:14.466 test[8796:c07] *** Assertionfailure in -[WGQ_ViewController doSomething:],/Users/king/Desktop/test/test/WGQ_ViewController.m:26

2013-07-13 10:31:14.467 test[8796:c07] *** Terminatingapp due to uncaught exception 'NSInternalInconsistencyException', reason:'index must not be zero'

如果测试条件返回NO，NSAssert 就会抛一个异常，异常处理程序捕获异常之后，会调用abort结束程序。并显示自定义的消息"index must not be zero"

。并同时显示出错文件,出错代码，调用函数等消息。他是一个程序跟踪的很好的手段。（C语言中使用断言NSCAssert.）

MAC开发，出现异常只会结束当前循环，iOS中，结束整个程序。

禁用NSAssert: targets – build setting –APPLE LLVM—release 中添加NS_BLOCK_ASSERTIONS.

XCode 4.6.3 默认情况下会禁用发布版本代码中得断言。

用法总结与注意事项：

1）在函数开始处检查传入参数的合法性

2）每个NSAssert 只检验一个条件，因为检验多个条件时，当断言失败，无法直观的判断是哪个条件失败

3）不能使用改变环境的语句,因为assert只在DEBUG个生效,如果这么做,会使用程序在真正运行时遇到问题 错误:

assert(i++< 100) 这是因为如果出错，比如在执行之前i=100,那么这条语句就不会执行，那么i++这条命令就没有执行。 

正确: assert(i < 100)  ；

i++;

4) assert和后面的语句应空一行,以形成逻辑和视觉上的一致感

5)有的地方,assert不能代替条件过滤

下面的代码是吧NSCAssert 包装为RNCAssert 在OC中使用断言的时候就应该使用NSAssert。

#define RNLogBug NSLog

// RNAssert and RNCAssert work exactly like NSAssert andNSCAssert

// except they log, even in release mode

#define RNAssert(condition, desc, ...) \

if (!(condition)){ \

RNLogBug((desc), ## __VA_ARGS__); \

NSAssert((condition),(desc), ## __VA_ARGS__); \

}

#define RNCAssert(condition, desc) \

if (!(condition)){ \

RNLogBug((desc), ## __VA_ARGS__); \

NSCAssert((condition), (desc), ## __VA_ARGS__); \

}

断言应该位于导致程序崩溃的代码之前。看下面的例子

RNAssert(foo !=nil,@"foo must not be nil");

[array addObject:foo];

如果这里会导致断言失败，那么关闭断言，程序依然会崩溃。所以要将代码改为下面这样：

RNAssert(foo != nil, @"foomust not be nil");

if (foo != nil) {

[array addObject:foo];

}

这样就好了，RNAssert 可以记录日志。但是代码有冗余，如果断言条件和if条件不匹配，就可能产生bug

if (foo != nil)

{

[arrayaddObject:foo];

}

else

{

RNAssert(NO, @"foo must not be nil");

}

这样就保证了断言条件跟if条件总是匹配的。这是一种比较好的断言使用方式。另外建议在switch语句的defualt分支中使用断言。

assert的缺点是，频繁的调用会极大的影响程序的性能,增加额外的开销。

插一点关于调试信息—几个宏（附加内容）：

1)__VA_ARGS__ 是一个可变参数的宏，很少人知道这个宏，这个可变参数的宏是新的C99规范中新增的，目前似乎只有gcc支持（VC6.0的编译器不支持）。宏前面加上##的作用在于，当可变参数的个数为0时，这里的##起到把前面多余的","去掉的作用,否则会编译出错, 你可以试试。 　　

2) __FILE__ 宏在预编译时会替换成当前的源文件名 　　

3) __LINE__宏在预编译时会替换成当前的行号 　　

4)__FUNCTION__宏在预编译时会替换成当前的函数名称

3. 异常

简单的说，在OC中，异常不是用来处理那些可恢复的错误的。异常是用来处理那些永远不应该发生却却发生了的错误，而这个时候应该结束程序运行。异常跟NSAssert比较像，事实上，NSAssert 就是作为异常实现的。

[NSException raise:@"WebService error" format:@"%@",@"测试111111"];

程序抛出异常的原因多种多样，可由硬件导致也可由软件引起。异常的例子很多，包括被零除、下溢和上异之类的数学错误，调用未定义的指令（例如，试图调用一个没有定义的方法）以及试图越界访问群体中的元素

网上找的例子：

NSException* ex = [[NSExceptionalloc]initWithName:@"MyException" reason:@"b==0" userInfo:nil];

@try

{

int b = 0;

switch (b)

{

case 0:

@throw(ex);//b=0，则抛出异常；

break;

default:

break;

}

@catch (NSException *exception)//捕获抛出的异常

{

NSLog(@"%@~~~%@",exception.name,exception.reason);

NSLog(@"b==0 Exception!");

}

@finally

{

NSLog(@"finally!");

}

[exrelease];

典型应用：

@try {

a = UIApplicationMain(argc, argv,nil,NSStringFromClass([PGAppDelegate class]));

}

@catch(NSException *exception) {

NSLog(@"Caught %@%@", [exception name], [exception reason]);

NSLog(@"Exception - %@",[exception callStackSymbols]);

exit(EXIT_FAILURE);

}

return a;

以下内容出自 Exception Programming Topics ：
Cocoa框架通常不是异常安全的。异常只用来处理程序员犯的错误，程序捕获到这种异常之后应该尽快退出运行。

在OC中，ARC默认情况不是异常安全的，有可能是因为异常而产生严重的内存泄露。理论上来说，OC++ 中得ARC是异常安全的。但是@autoreleasepool块任然可能导致后台线程发生内存泄露。使用异常安全的ARC会导致性能下降，这也是应该避免大量使用OC++的原因之一。在Clang中，制定-fobjc-arc-exception 编译标志就可使用异常安全的ARC。