try catch final is not catching exception - iphone

Question

While on return to my app from getting phone number from address book, if by mistake i fetch some address or any thing except for phone number, the code in the try catch final gives the following but doesn't catch it, any idea is appreciated in advance:
*** -[CFDictionary length]: message sent to deallocated instance 0x6a4db70
Code:
strContact = (NSString *)phone; CFRelease(phone);
// NSLog(#"%#", strContact);
CFRelease(multi);
name = (NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);
NSRegularExpression *regex = [[[NSRegularExpression alloc] initWithPattern:#"[a-zA-Z]" options:0 error:NULL] autorelease];
// Assuming you have some NSString myString.
NSUInteger matches = [regex numberOfMatchesInString:strContact options:0 range:NSMakeRange(0, [strContact length])];

Answer 1

OK, I think I understand your question now. It just took me a while.
So, I'm assuming you have Zombie Objects enabled (NSZombieEnabled) and you're wondering why you can't catch this error --sending a message to a zombie-- with a #try/#catch structure.
The short answer is NSZombies don't throw an Objective-C exception (one that you can catch this way). There wouldn't really be a point to that, since you wouldn't actually ship an app with NSZombieEnabled anyway. This is meant to be a debugging tool that you use at the debugger or within Instruments.
In your actual app, when you turn off NSZombie's, there still wouldn't be an exception to catch for this, since you would just get an EXE_BAD_ACCESS, which is a UNIX signal (not this type of an exception at this level).
The last point is that Objective-C exceptions (the type that you can #try/#catch) are not recommended for errors that you expect to be able to recover from. Or in other words, this is meant for fatal errors only, where you might do some cleanup and then allow your app to still crash.
The right way to do what you're trying to do is to actually test for different types or different values that you might except to get and then handle each case appropriately. You can do this using normal if/else conditionals or something of that sort. You can test values for nil if you need to and you can see if an object is of a particular class by using [someObj isKindOfClass:[MyExpectedClass class]]
I hope I understood the question correctly?

Answer 2

The problem is probably that you are releasing phone after assigning it to strContact, and then using strContact. The string object is probably getting deallocated when you release phone, so the pointer in strContact is no longer valid.

Answer 3

Are you sure that phone is a string? Looks like you're storing that object in a NSString* pointer 'strContact' that is probably not a string, hence the 'CFDictionary' in the error messages.
Looks like you have two problems to fix:
Getting the object of the right type.
Ensuring that you don't release objects before you need to. Try put the CFRelease after you've finished using the object!