建议大型项目用上Try Catch
建议大型项目用上Try Catch
我们在平时项目做功能的时候，经常会遇到崩溃的情况。如果是我们在开发测试阶段，我们可以找到原因修复。但是遇到已经上线，出现这种问题。要么使用JSPatch进行热修复，但是使用热修复修复苦只有写的人知道。
本来就是一个方法一个单词写错，一个值没做异常处理，就要重写整个方法。对于像我这样根本不懂JS语法和不精通JSPatch的人来说，真的是蓝瘦，香菇。
最近写的项目用Swift语法进行编写的，对于之前我们在Object-C中NSError**类型的指针标识遇到了什么错误，现在转成Swift方法直接进行throws进行抛异常。
这样我们就必须使用Do Catch进行捕获异常了，我觉得苹果这样做真的挺好的。
比如我刚刚写的项目，就用上了，感觉用完顿时高大上了许多。
import Cocoa
enum OFileMagerImportError:Error {
case cannel //点击了取消的按钮
case error(message:String)
}
class OFileManger: NSObject {
/*
* 导入配置文件
* return 返回一个数组对象 可能返回为空
*/
class func importAction() throws -> [Any] {
let openPannel = NSOpenPanel()
openPannel.allowedFileTypes = ["ork"]; // 只允许读取.ork的文件类型
openPannel.allowsMultipleSelection = false // 设置不允许多选
let buttonIndex = openPannel.runModal()
guard buttonIndex == NSFileHandlingPanelOKButton else {
throw OFileMagerImportError.cannel
}
guard openPannel.urls.count > 0 else {
throw OFileMagerImportError.error(message:"你还没有选择任何的配置文件!")
}
guard let fileName = openPannel.urls.first else {
throw OFileMagerImportError.error(message:"你还没有选择任何的配置文件!")
}
guard let jsonData = try? Data(contentsOf: fileName) else {
throw OFileMagerImportError.error(message:"读取文件内容失败!")
}
guard let jsonObj = try? JSONSerialization.jsonObject(with: jsonData, options: .allowFragments) else {
throw OFileMagerImportError.error(message:"配置文件内容不是一个JSON文本!")
}
guard let configList:[Any] = jsonObj as? [Any] else {
throw OFileMagerImportError.error(message:"配置文件内容不是一个数组对象!")
}
return configList
}
}
调用的时候我们可以这么写。
@IBAction func importAction(_ sender: Any) {
do {
let configList:[Any] = try OFileManger.importAction()
print(configList)
} catch OFileMagerImportError.error(let message) {
OAlertMessage.alert(message: message)
} catch {
print("抛出了其他不给用户看到的错误!")
}
}
我们就可以做一些错误的处理。但是只是这样，我心里面还不是十分强烈想用。
后来线上的App在双11那天晚上突然出现打不开崩溃的情况，在外面准备吃饭庆祝的强行喊回去解决问题。
回去觉得应该是那里崩溃了吧，应该也是十分的容易解决。
后来发现因为接口因为最近上线的功能出问题了，就回滚了代码。导致之前一些接口的字段没有返回，恰好那个接口没有用Model进行映射，所以就出现崩溃了。
经理一直问这个接口回滚好几天了为啥突然出问题了，原来是接口做了缓存，会根据后台返回是否需要更新才会重新的请求接口。
双11那天正好运维更新了数据，导致接口重新请求，少了字段导致崩溃。最后让后台强行把拿两个字段返回，最快的解决问题。
虽然让后台加上了字段，但是我觉得我们App这里没有做好兼容，才导致这一次事故。幸亏没影响多久，再说客户都是外国人，那个时间还没睡醒。
我们平时遇到的一些崩溃问题所在
- 数组越界
- 给一个可变数组强行赋值不可变，之后当做可变数组用
- 字典值不存在
- 后台返回的字段不统一，本来有值是字典，没值是字符串。
导致的崩溃自然不止这些，但是这些占据了崩溃里面大部分，前三个我们可以做一下异常处理，最后一个最好还是让后台规范起来，这是长远之际。或者使用Model进行映射。
怎么做异常处理
- 做很多
if else判断 - 使用
Try catch进行处理
虽然两个都要写很多的代码，if else的代码更加优美一点，但是就怕有一种情况你没写出来。觉得最好的办法还是用try catch进行。
@try，@catch，@throw，和 @finally。这四个关键词进行异常处理。
我们看一下常见的一个数组越界的例子：
NSArray *tests = @[];
NSNumber *num = tests[0];
我们不用运行就可以知道这个地方会崩溃，因为我们初始化的数组是空的。但是我们强行取一个元素，导致崩溃。
假设我们现在用上了try catch的代码，会如何呢。
NSArray *tests = @[];
@try {
NSNumber *num = tests[0];
} @catch (NSException *exception) {
NSLog(@"%@",exception.userInfo);
} @finally {
NSLog(@"我做一些必须的处理");
}
经过测试，这个代码会在Debug的时候断点，但是强行运行还是可以运行的。但是在Release发布之后运行完全没有任何的影响。
虽然我们平时写代码上面，不可能让所有出现异常的地方写上这样的代码。但是对着我们的经验，我们对于一眼就知道会出崩溃的地方加上，还是能让线上的应用少出很多问题的。
关于Try catch的资料可以查看下面资料：
