2

I need to protect my code against possible errors. If they arise then there's no point to run the app further, so I need to bring to the user some message and then exit the app. So, I'm checking the conditions and then bringing alert:

if (someError){    
  UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error" message:@"No database file exist. App will close now." delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
  [alert show];
  [alert release]; 
}

And in the delegate method I'm closing the app using NSAssert:

-(void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex {
  if (buttonIndex == 0) {
    NSAssert(0, @"closing");
  }
}

Also, I have included delegate protocol in header. However, the app just brings alert but after pressing OK it just freezes, and I'm getting some message "CoreAnimation: ignoring exception: closing". What am I missing or what other options exits?

Centurion
  • 14,106
  • 31
  • 105
  • 197

1 Answers1

2

You should not do that, it is against Apple HIG (Human Interface Guidelines):

iPhone applications should never quit programmatically because doing so looks like a crash to the user.

It is always better to provide some kind of feedback to the user about the error that occured and provide a way to restart the process without restarting the app. However, if you really, really want, you can use 

exit(0);
mja
  • 5,056
  • 1
  • 29
  • 40
  • OK but why then NSAssert exits? I saw the use of it in "Beginning iOS 4 application development" book where author shows how to work with SQLite. The presented examples use NSAssert for closing the app at critical errors, for example no SQLite database file exists and etc. – Centurion Sep 20 '11 at 07:13
  • yep, consider NSAssert as a safeguard, used mainly during the development to make sure you have consistent state of your app. Asserts may be left in place in production code as well... However asserts are used mainly to handle unexpected errors rather than the one you expect to happen at some point. Always try to recover from error if possible (e.g. with "Retry" button). – mja Sep 20 '11 at 07:19
  • further, assert does not 'clean' shutdown with 0 exit code, however it does crash the app (and produce crashlog) - you may even get rejected during the review process if your app repeatedly crashes under certain circumstances. – mja Sep 20 '11 at 07:20
  • Thanks. However, if somebody wants to implement really nice user experience then he should implement (or write himself) a solid error/exception handling framework. It's interesting how much apps have it, I guess very few :) IMHO it's a lot of work if we want to create a very very clever app that is bundled with all possible error predictions and solutions. – Centurion Sep 20 '11 at 07:26
  • i agree that ios error handling is less powerful than the options you have in AppKit (Mac), however, you should be able to put together consistent error handling with the use of basic mechanisms described in [Error Handling Programming Guide](http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorHandling/ErrorHandling.html#//apple_ref/doc/uid/TP40001806-CH201-SW1) and [Exception Programming Topics](http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/Conceptual/Exceptions/Exceptions.html#//apple_ref/doc/uid/10000012i) – mja Sep 20 '11 at 07:30