CODEWITHSUNDEEP
objective-c
AdamM
AdamM

Reputation: 4440

Objective-C should I be using NSError and why presentError function not working

I am creating an application on iPhone where I am taking code written and Java and translating into Objective-C, as the app must work similarly in both Android and iPhone. Now problems of course are there are certain areas where the languages differ quite a bit, and can be difficult to implement just right.

One of the areas where it is of course different is you cannot create NSMutableArrays or NSMutableDictionaries which only accepts objects of a certain type. So when I am creating the getters and setters for these objects, I have been doing this, example below:

  -(void)setPerson:(NSMutableArray *)personList_p
    {
        BOOL bAllowed = YES;
        for(int i = 0; i < [personList_p count]; i++)
        {
            if(![[personList_p objectAtIndex:i] isKindOfClass:[Person class]])
            {
                bAllowed = NO;
                break;
            }
            else
            {
                bAllowed = YES;
            }
        }

        if(bAllowed)
        {
        personList_i = personList_p;
        }
        else
        {
        //Raise error here
        }
    }

Now originally I was using NSRaise Exception, but after doing reading up on it, it recommends against this as exception handling is resource intensive and should not be used for this type of situation. So NSError I read was a good solution, so I was reading up on this guide

http://www.cimgf.com/2008/04/04/cocoa-tutorial-using-nserror-to-great-effect/

My question is two fold, if I decide to use NSError should, is it best practice to declare the NSError object in the method, i.e like this

-(void)setPerson:(NSMutableArray *)personList_p : (NSError **)error

Or is it okay just to declare the error within the else statement above, like this

 NSError *error = nil;
         NSMutableDictionary* details = [NSMutableDictionary dictionary];
                [details setValue:@"Invalid object passed into Array, object must be of type Person." forKey:NSLocalizedDescriptionKey];
                error = [NSError errorWithDomain:@"Invalid Object" code:200 userInfo:details];
                NSLog(@"%@", [error localizedDescription]);

Secondly, in the guide I linked above, in the conclusion the author says

In this example, I am checking to see if the error is still nil after my message call. If it is no longer nil I know that an error occurred and that I need to display it to the user. Apple provides a built in method to do this with a call to presentError: on the NSApplication instance

and he uses this line of code here

[NSApp presentError:error];

This does not work for me, I do not get an autocomplete option with this code, just says use of undeclared identifier. Am I missing something obvious here?

Also, just to be sure, is the method I am using, the best method to go about ensuring the user sends in an array with the correct object types? Or is there another method which could be used which would achieve the same thing but in a more efficient manner.

Thanks in advance!!

EDIT:

Additional question, would it be such a bad idea to use NSException, as the problem with NSError is the app carries on, I am considering having it so if they do pass in an array with an invalid object, that it does just cause the application to crash and raise an exception. Is there any major reason why I shouldn't do this??

Upvotes: 0

Views: 1148

Answers (1)

CodaFi
CodaFi

Reputation: 43330

Now originally I was using NSRaise Exception, but after doing reading up on it, it recommends against this as exception handling is resource intensive and should not be used for this type of situation. So NSError I read was a good solution, so I was reading up on this guide

He does not actually say that raising exceptions is inherently bad or resource intensive, he argues that @try/catch is the wrong way to go about things. That, and Cocoa applications (even more so I'm Cocoa-Touch) should refrain from throwing exceptions whenever possible. Exceptions indicate undefined behavior, not simple errors.

Secondly, in the guide I linked above, in the conclusion the author... uses this line of code here

[NSApp presentError:error];

This does not work for me, I do not get an autocomplete option with this code, just says use of undeclared identifier. Am I missing something obvious here?

That is because NSApp is a concept only accessible to Cocoa(or Mac) applications. It represents a pointer to "the application itself", and has some pretty neat functions associated with it. Of course, iOS has no parallel concept, so errors are traditionally presented in a UIAlertView.

Additional question, would it be such a bad idea to use NSException, as the problem with NSError is the app carries on, I am considering having it so if they do pass in an array with an invalid object, that it does just cause the application to crash and raise an exception. Is there any major reason why I shouldn't do this??

It is generally a bad idea to use NSException for anything other than extremely serious logic (such as when a call is made to an index out of the bounds of an NSArray, or when a UITableView's data source happens to be out of sync with what the table demands). If you absolutely must stop program execution, it's much cleaner to use NSAssert() to throw conditional exceptions. And even then, setters are not the place to be throwing exceptions. It would be far easier to simply return nil when the condition fails, then have the caller check for such an outcome and handle it appropriately.

Upvotes: 2

Related Questions