All geek questions in one place

Handling Errors and Exceptions on iPhone

I am developing a Core Data application for 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 persistent storage. For example, look at the Locations master data tutorial (hope it’s OK to quote it here as follows):

(Se comments in code for some of my neighbors)

- (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 where to look for errors, where to look for exceptions, how and when to spread them up and how to handle serious errors on the iPhone correctly?

Edit: after receiving some answers to this and my other related question, I have some clarifications that I'm trying to ask:

Now I understand the exceptions from cocoa, mainly for finding programmer errors, not runtime errors. Could you refuse to handle exceptions when sending the application (if it was not added for debugging reasons)? Or should I still program the protection and use a lot of @try anyway?

Since iPhone applications are isolated and the user cannot get into the file system, what possible runtime errors can be useful in developing a basic sqlite-based data application? I mean, the database file is unlikely to disappear ... but perhaps updating in the future may lead to the abandonment of the old invalid sqlite database .... what is good practice?

Also, other things, such as object distribution, are unlikely to fail? You will receive a low memory warning long before this happens .... or ...?

And what is good programming practice dealing with errors and exception handling in the example above, where I can get the error "deep down" in the methods ... should I handle the error there or wait until it reaches the top in some form (for example, a null object) or process them all in a chain reaction?

And how to deal with them? Log in to NSLog and continue? Show a modal information window and block waiting for a user to exit the application? Or "Error xxx, click OK to close the application"?

And is there a way to show the modal dialog directly? I noticed that some of the errors that I provoked that displayed the dialog never showed that, as the application continued and then crashed ... is there a SHOW NOW way?

A lot of questions, I hope you will be interested to answer at least some of them, and that this may be interesting for others!

Rgds PM

0
source share
3 answers

As I said in a comment on your other question, exceptions are used only by the Cocoa API to indicate things that look like the programmer is wrong - the array goes out of bounds, the Core Data database has the wrong scheme, etc. Errors are used to indicate what may happen to the user - the file does not exist, the network operation is not completed, etc. As a rough rule of thumb, pay attention to exceptions during development and crush them as errors introduced by the programmer. Be prepared to handle and recover from manufacturing errors.

One of the important edge cases on a Mac is Distributed Objects, which uses exceptions for things like the other end of the connection, or a security check fails.

+2
source

You should check for errors if the documentation says so.

For example, in the documentation for NSPersistentStoreCoordinator: addPersistentStoreWithType: configuration: URL: options: error: documentation, note that it says:

Return value

A newly created repository or, if an error occurs, nil.

This means that in case of an error, nil is returned. You should check this because otherwise you will have a reference to nil, which will throw an exception at runtime as soon as you try to use it. This is not an elegant way to run an application — unexpected crashes — it is simply unacceptable behavior for any type of user application.

In Objective-C, you usually don't need to deal with exceptions because they are used for exceptional situations. Some other languages ​​use exceptions as the best way to indicate normal error conditions for a variety of very good reasons. This, however, is not a convention in Objective-C.

So, the answer to your question is: you should always handle errors when the API tells you that a function can return zero in case of an error.

If the documentation says that you expect and handle exceptions, do it. Otherwise, no. The only exception is iff , you know what you are doing and why.

+1
source

Source: https://habr.com/ru/post/1308166/

More articles:


All Articles