我搜索了一些这些NSRangeException
错误帖子,但似乎无法找到我的问题的答案。这是我的错误:
2015-08-15 17:28:43.793 UTK Recruiting [8794:254203] *由于未捕获的异常'NSRangeException'而终止应用,原因:'* - [__ NSArrayI objectAtIndex:]:index 3超出界限[0 .. 2]' ***首先抛出调用堆栈:
这是一些代码。基本上我正在浏览文档目录,获取所有文件名和路径,然后我尝试用文件名填充UITableView
,以便可以选择一个单元格,然后该文件可以附加到电子邮件中。以下是我的一些代码:
解析文档目录,将所有csv文件放在相应的数组中。
- (void) refreshTable {
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSArray *documentArray = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:documentsDirectory error:nil];
NSArray *csvFiles = [documentArray filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(NSString *evaluatedObject, NSDictionary *bindings) {
return [evaluatedObject hasSuffix:@".csv"];
}]];
self.csvFileNames = (NSMutableArray*) csvFiles;
self.csvFilePaths = [NSMutableArray arrayWithCapacity:[csvFiles count]];
for (NSString *fileName in csvFiles) {
[self.csvFilePaths addObject:[documentsDirectory stringByAppendingPathComponent:fileName]];
}
NSLog(@"files array %@", _csvFileNames);
NSLog(@"files array %@", _csvFilePaths);
这是UITableView代码:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
// Return the number of sections.
return 1;
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
// Return the number of rows in the section.
NSLog(@"count: %lu", (unsigned long)[self.csvFileNames count]);
return [self.csvFileNames count];
}
-(UITableViewCell *)tableView:(UITableView *)tableView cellforRowAtIndexPath:(NSIndexPath *)indexPath {
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
cell.textLabel.text=[self.csvFileNames objectAtIndex:indexPath.row];
return cell;
}
在我的代码中放置断点后,我发现它在cellForRowAtIndexPath
方法中崩溃,这是我发布的代码中的最后一个方法。 cellForRowAtIndexPath方法根本不运行。还有一点需要注意的是,有4个csv文件,而[self.csvFileNames count]
正确地给出了数字4。
代码应该运行到索引3,但我无法弄清楚它为什么不是。
bt所有崩溃报告:
主题#1:tid = 0x56469,0x0000000109200286> libsystem_kernel.dylib
__pthread_kill + 10, queue = 'com.apple.main-thread', stop >reason = signal SIGABRT frame #0: 0x0000000109200286 libsystem_kernel.dylib
__ pthread_kill + 10 帧#1:0x000000010923342f libsystem_pthread.dylibpthread_kill + 90 frame #2: 0x0000000108fa019a libsystem_sim_c.dylib
abort + 129 第3帧:0x0000000108d8b481 libc ++ abi.dylibabort_message + 257 frame #4: 0x0000000108db33d5 libc++abi.dylib
default_terminate_handler()+ 267 帧#5:0x0000000101e4be19 libobjc.A.dylib_objc_terminate() + 103 frame #6: 0x0000000108db0b01 libc++abi.dylib
std :: __ terminate(void(*)())+ 8 第7帧:0x0000000108db07aa libc ++ abi.dylib__cxa_rethrow + 99 frame #8: 0x0000000101e4bd2c libobjc.A.dylib
objc_exception_rethrow + 40 帧#9:0x00000001020db41e CoreFoundationCFRunLoopRunSpecific + 654 frame #10: 0x0000000104e74a3e GraphicsServices
GSEventRunModal + 161 帧#11:0x00000001025ab8c0 UIKit`UIApplicationMain + 1282
- 第12帧:0x000000010176311f UTK招募
main(argc=1, argv=0x00007fff5e4a04f8) + 111 at main.m:14 frame #13: 0x0000000108ef8145 libdyld.dylib
开始+ 1 帧#14:0x0000000108ef8145 libdyld.dylib`start + 1线程#2:tid = 0x564a0,0x0000000109201232 libsystem_kernel.dylib
kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x0000000109201232 libsystem_kernel.dylib
kevent64 + 10 第1帧:0x0000000108eb376c libdispatch.dylib_dispatch_mgr_invoke + 247 frame #2: 0x0000000108eb3511 libdispatch.dylib
_ dispatch_mgr_thread + 54线程#3:tid = 0x564a2,0x000000010920094a libsystem_kernel.dylib
__workq_kernreturn + 10 frame #0: 0x000000010920094a libsystem_kernel.dylib
__ workq_kernreturn + 10 第1帧:0x00000001092316c3 libsystem_pthread.dylib_pthread_wqthread + 869 frame #2: 0x000000010922f40d libsystem_pthread.dylib
start_wqthread + 13线程#4:tid = 0x564a3,0x000000010920094a libsystem_kernel.dylib
__workq_kernreturn + 10 frame #0: 0x000000010920094a libsystem_kernel.dylib
__ workq_kernreturn + 10 第1帧:0x00000001092316c3 libsystem_pthread.dylib_pthread_wqthread + 869 frame #2: 0x000000010922f40d libsystem_pthread.dylib
start_wqthread + 13线程#5:tid = 0x564a4,0x000000010920094a libsystem_kernel.dylib
__workq_kernreturn + 10 frame #0: 0x000000010920094a libsystem_kernel.dylib
__ workq_kernreturn + 10 第1帧:0x00000001092316c3 libsystem_pthread.dylib_pthread_wqthread + 869 frame #2: 0x000000010922f40d libsystem_pthread.dylib
start_wqthread + 13线程#6:tid = 0x564a5,0x000000010920094a libsystem_kernel.dylib
__workq_kernreturn + 10 frame #0: 0x000000010920094a libsystem_kernel.dylib
__ workq_kernreturn + 10 第1帧:0x00000001092316c3 libsystem_pthread.dylib_pthread_wqthread + 869 frame #2: 0x000000010922f40d libsystem_pthread.dylib
start_wqthread + 13
返回声明中的main.m崩溃:
int main(int argc, char * argv[]) {
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
更新:我一直在浏览许多其他NSRangeException线程,到目前为止没有运气。
答案 0 :(得分:0)
如果你认为它来自UITableView
它不会从线程调用,它总是只从主线程调用。
尝试在项目中添加Exceptional Breakpoint,如屏幕截图所示,因此它会在崩溃发生之前停止。
您可以找到崩溃线并确定问题的确切位置
答案 1 :(得分:0)
当然它崩溃了主线程 - 它是一个未被捕获的例外。为所有异常添加断点应突出显示[self.csvFileNames objectAtIndex:indexPath.row]。
iOS的属性系统永远不会失败。
我能想到的唯一解释是,在填充表格视图时,您的数组会被取消/修改。
检查方法refreshTable被调用的频率和位置。它应该是一次。
将NSLog放入tableView:cellforRowAtIndexPath:也无法在执行期间验证数组是否保持不变。
另一个,但不寻常且可能不太可能,解释可能是修改后的NSArray类。 (例如,NSArray的类别改变了objectAtIndex的行为:。常见一次。但你应该知道你是否添加了任何NSArray / NSMutableArray类别。
方法调用的替换可以是键控下标。
cell.textLabel.text = self.csvFileNames[indexPath.row];