UITableView Crashes Whenever Going Beyond Total Cell Values

[jakerocheleau]

So I have a small plist loaded into a UITableView which displays different endings to a game. Currently when you flick either up or down beyond the table's 8 total values the app crashes and Xcode displays this error:

2012-02-08 14:02:28.074 SaveTheHomeland[3995:f803] -[__NSCFString tableView:cellForRowAtIndexPath:]: unrecognized selector sent to instance 0x6a5add0
2012-02-08 14:02:28.079 SaveTheHomeland[3995:f803] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString tableView:cellForRowAtIndexPath:]: unrecognized selector sent to instance 0x6a5add0'
*** First throw call stack:
(0x13bc052 0x154dd0a 0x13bdced 0x1322f00 0x1322ce2 0xace0f 0xad589 0x98d44 0xa7851 0x52322 0x13bde72 0x1d6692d 0x1d70827 0x1cf6fa7 0x1cf8ea6 0x1d9237a 0x1d921af 0x1390966 0x1390407 0x12f37c0 0x12f2db4 0x12f2ccb 0x12a5879 0x12a593e 0x13a9b 0x23f8 0x2355 0x1)
terminate called throwing an exception

I'm trying to build the app programmatically with no Storyboard whatsoever. I don't think this is the problem, though.. would love any help I can get on this issue.

You can download my source code if you wanna run it within Xcode yourself.

[BrianSlick]

The delegate message is being sent to an NSString. Sounds like you have a memory management problem. Or you've assigned the wrong object as the delegate.

[jakerocheleau]

Originally Posted by BrianSlick

The delegate message is being sent to an NSString. Sounds like you have a memory management problem. Or you've assigned the wrong object as the delegate.

not sure I follow you but what is the 'delegate method'?

I'm using an NSString to fill in the title for each cell, and beyond my 8 cells there are no titles left. So the script may be trying to find an NSString which doesn't exist, then crashing?

I have a screenshot below, and I also added my AppDelegate code since this may be useful? Been debugging for a couple of hours and it has me wracking my brain.

# AppDelegate.h
#import <UIKit/UIKit.h>

#import "EndingsTableViewController.h"

@interface AppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

@end

# AppDelegate.m
#import "AppDelegate.h"

@implementation AppDelegate

@synthesize window = _window;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    
    EndingsTableViewController *endingsController = [[EndingsTableViewController alloc] initWithStyle:UITableViewStylePlain];
    UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:endingsController];
    
    [self.window addSubview:navController.view];
    
    [self.window makeKeyAndVisible];
    
    return YES;
}

@end

[BrianSlick]

See the link in my signature for guidance.

[RickSDK]

you may be setting the numberOfRowsInSection too high for the cellForRowAtIndexPath function to handle. Those two need to be in sync, especially if you are using arrays.

You can always try commenting out most of the code in your cellForRowAtIndexPath function and then add it back in 1 line at a time until you find the problem.

[BrianSlick]

Originally Posted by RickSDK

you may be setting the numberOfRowsInSection too high for the cellForRowAtIndexPath function to handle. Those two need to be in sync, especially if you are using arrays.

You can always try commenting out most of the code in your cellForRowAtIndexPath function and then add it back in 1 line at a time until you find the problem.

That would be an array out of bounds error. That's not what this is.

[GHuebner]

Why not set an Exception Breakpoint on all exceptions to see what line of code is failing. That way you wont be returned to the AppDelegate code where you really can't see what caused the issue.

Originally Posted by BrianSlick

That would be an array out of bounds error. That's not what this is.

[jakerocheleau]

Originally Posted by GHuebner

Why not set an Exception Breakpoint on all exceptions to see what line of code is failing. That way you wont be returned to the AppDelegate code where you really can't see what caused the issue.

yeah I'm not familiar with how to do that but I recall reading about it on Stack.

NSLog some type of formatted output?

[BrianSlick]

There are really only 2 possibilities here:

1. The wrong object has been set as the delegate
2. The object set as the delegate has died

That's pretty much it.

[GHuebner]

It looks like your initial error is also now different than the current one you posted.

Initial Exception:

'NSInvalidArgumentException', reason: '-[__NSCFString tableView:cellForRowAtIndexPath:]

Current Exception:

'NSInvalidArgumentException', reason: '-[__NSCFArray tableView:cellForRowAtIndexPath:]

Originally Posted by BrianSlick

There are really only 2 possibilities here:

1. The wrong object has been set as the delegate
2. The object set as the delegate has died

That's pretty much it.

[BrianSlick]

When the receiving object class changes in an error message, that suggests memory management problem. So that would be #2 I mentioned above.

[GHuebner]

Thanks Brian,

I noticed the discrepancy but didnt know the link to memory management issues. Now at least I can look for that when I am debugging as well.

Originally Posted by BrianSlick

When the receiving object class changes in an error message, that suggests memory management problem. So that would be #2 I mentioned above.

[jakerocheleau]

got it! The issue is with my UITableViewController releasing in memory.

This has something to do with ARC.. anyways in my AppDelegate.m I just changed this line:

[self.window addSubview:navController.view];

with this:

[self.window setRootViewController:navController];

and now the whole thing runs great. Plus now I know going forward on future apps

[BrianSlick]

Nothing to do with ARC. Keeping the view alive (the first case) doesn't mean anything as far as keeping the view controller alive. The second case, which is indeed what you should be doing these days, keeps the controller alive.

I was trying to figure out how you'd have the table view alive while it's view controller died. Now I understand.