处理iPhone上的错误和异常 [英] Handling errors and exceptions on the iPhone
问题描述
我的问题是，我应该多少寻找和处理错误和异常，例如打开永久存储时。看看位置核心数据教程（希望它可以这样引用它）：
（在我的一些保存的代码中的注释）
- （void）applicationDidFinishLaunching：（UIApplication *）application {
...
NSManagedObjectContext * context = [self managedObjectContext];
if（！context）{
//处理错误。这个代码可能会发生吗？ （见下面的评论）
- （NSManagedObjectContext *）managedObjectContext {
...
NSPersistentStoreCoordinator * coordinator = [self persistentStoreCoordinator];
//似乎即使我在persistentStoreCoordinator中收到错误或异常，
//协调器仍然不会为零，还是？
if（coordinator！= nil）{
managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator：coordinator];
}
return managedObjectContext;
}
- （NSPersistentStoreCoordinator *）persistentStoreCoordinator {
...
NSError *
//我应该有一个：如果managedObjectModel！= nil在这里？
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] [initWithManagedObjectModel：[self managedObjectModel]];
//这里还需要一个@try吗？
if（！[persistentStoreCoordinator addPersistentStoreWithType：NSSQLiteStoreType configuration：nil URL：storeUrl options：nil error：& error]）{
//处理错误，做什么？
}
return persistentStoreCoordinator;
}
- （NSManagedObjectModel *）managedObjectModel {
...
//应该有@try这里？但是如何处理捕获的异常？刚退回零？
managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles：nil] retain];
返回managedObjectModel;
}
所以问题是真正在哪里寻找错误，在哪里寻找例外，如何以及何时向上传播，以及如何处理iPhone上的严重错误？
编辑：在收到一些这样的回答和我的其他相关问题后，我已经清楚了我尝试的问题：
我现在明白可可的异常主要是为了找到程序员的错误，而不是运行时错误。在运送应用程序时，如果不包括任何异常处理（如果没有为调试原因添加），您是否会去？或者我还应该防御程序，还是使用很多的@try？
由于iPhone应用程序是沙盒，用户无法访问文件系统，可能的运行时错误在设计基于sqlite的核心数据应用程序时，可以很方便地寻找？我的意思是，数据库文件不太可能会消失....但也许未来的升级可能会失败，留下一个旧的无效的sqlite数据库....什么是好的做法？
另外，像对象分配这样的其他东西也是不太可能失败的？你会得到一个低的内存警告很久以前发生....或...？
而且，在上面考虑错误和异常处理是什么好的编程练习例如，我可以在方法中得到一个错误深层次...我应该在那里处理错误，或者等到它以某种形式（例如一个零对象）到达顶部，或者在链中处理它们反应？
而且，如何处理？登录到NSLog并继续？显示模态信息框并锁定等待用户退出应用程序？或者错误xxx，按确定退出应用程序？
而且，是否有任何方式直接显示模态对话？我注意到，我挑衅的一些错误会显示一个对话框，从来没有显示出因为应用程序继续而且后来崩溃了....是否有一个SHOW NOW方法？
很多问题，希望你有兴趣回答至少一些，这可能是别人的兴趣！
Rgds
PM
正如我在对其他问题的评论中所说的，Cocoa API仅使用异常来表示程序员有错误 - 一个数组是超出范围的，一个Core Data数据库有错误的模式等。错误用于指示用户可能会发生的事情 - 文件不存在，网络操作未完成等。所以作为一个粗略的经验法则，在开发过程中寻找异常，并将其作为程序员引入的错误。准备处理和从生产中的错误中恢复。
Mac上的一个重要的边缘案例是分布式对象，它使用异常，如连接的另一端离开或安全验证不成功。
I am developinga Core Data app for the iPhone, and I am new to the whole platform etc.
My question is, how much should I look for and handle errors and exceptions, for example when opening up the persistent store. Looking at the "Locations" Core Data Tutorial for example (hope its OK to quote it here like this):
(Se comments in the code for some of my conserns)
- (void)applicationDidFinishLaunching:(UIApplication *)application {
...
NSManagedObjectContext *context = [self managedObjectContext];
if (!context) {
// Handle the error. Can this ever happen with this code? (see next comment below)
- (NSManagedObjectContext *) managedObjectContext {
...
NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
// it seems even if I get an error or exception down in persistentStoreCoordinator,
// coordinator will still never be nil, or?
if (coordinator != nil) {
managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator: coordinator];
}
return managedObjectContext;
}
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
...
NSError *error;
// should i have an: if managedObjectModel != nil here?
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] [initWithManagedObjectModel: [self managedObjectModel]];
//need a @try here too?
if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:nil error:&error]) {
// Handle error, do what?
}
return persistentStoreCoordinator;
}
- (NSManagedObjectModel *)managedObjectModel {
...
//should have a @try here? But how to handle caught exceptions? Just return nil?
managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:nil] retain];
return managedObjectModel;
}
So the question is really where to look for errors, where to look for exceptions, how and when to propagate them upwards, and how to handle severe errors on the iPhone in a good way?
Edit: after receiving some answers to this and my other related question I have some clearifications of what I try to ask:
I now understand exceptions in cocoa are mostly for finding programmer errors, not runtime errors. Would you go as far as not including any exception handling when shipping the app (if not added for debug reasons)? Or should I still program defensively and use a lot of @try anyway?
As the iPhone apps are sandboxed and the user cant get to the file system, what possible runtime errors are smart to look for when designing a sqlite based core data app? I mean, the database file is not likely to disapear....but perhaps a future upgrade could fail leaving an old invalid sqlite database....what is good practise?
Also, other things like object alloc are probaly extremely unlikely to fail? You would get a low memory warning long before that happens....or...?
And, what is good programming practise considering error and exception handling in the above example, where I can get an error "deep down" in the methods...should I handle the error down there or wait until it reaches the top in some form (a nil object for example), or handle them all in a chain reaction?
And, how to handle them? Log to NSLog and go on? Show a modal info box and lock up waiting for the user to exit the app? Or "Error xxx, press OK to exit app"?
And, is there any way to show a modal dialog directly? I noticed that some errors I provoked that would display a dialog never showed that because the app continued and later crashed....is there a SHOW NOW method?
Lots of questions, hope you would be interested to answer at least some of them, and that this could be of interest to others!
Rgds PM
As I said in a comment on your other question, exceptions are only used by the Cocoa API to indicate things that it looks like the programmer has got wrong - an array is out of bounds, a Core Data database has the wrong schema etc. Errors are used to indicate things which the user could cause to happen - a file doesn't exist, a network operation didn't complete etc. So as a rough rule of thumb, look for exceptions during development and crush them as programmer-introduced bugs. Be prepared to handle and recover from errors in production.
The one important edge case on the Mac is Distributed Objects, which uses exceptions for things like the other end of the connection going away or the security validation not succeeding.
这篇关于处理iPhone上的错误和异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
