我们可以通过使用@try，catch 机制来防止崩溃吗？如果错误是 -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array答案

【问题标题】：can we prevent crash by using @try, catch mechanism .if the error is -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array我们可以通过使用@try，catch 机制来防止崩溃吗？如果错误是 -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array
【发布时间】：2013-06-06 11:43:43
【问题描述】：

我是 iPhone 新手，

我们的团队创建了一个应用程序并上传到“AppStore”，我们还集成了“Bug Sense”。

现在我们的应用因崩溃而受到负面评价，我们在 iPhone/iPad 6.1.3 中测试了我们的应用

在我的错误意义上，我们得到了如下报告：

第一个错误：

-[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array [open]

第二次错误：

-[__NSArrayM objectAtIndex:]: index 61 beyond bounds for empty array [open]

现在在我的项目中，我将 @try{ } catch 块放置到使用“objectAtIndex”的方法中以防止崩溃，

我也设置了条件，即如果数组计数大于“0”，那么只有它会进入我使用“objectAtIndex”的条件

我的问题是，我们能否通过使用 @try, catch mechanism 来防止上述错误崩溃。

提前致谢

【问题讨论】：

嗯，处理数组边界错误的最好方法是不让它们出现——首先编写合理的代码并预先检查是否有任何可疑的理由。在某些情况下你可以使用 try/catch 来捕捉错误，但是 Objective-C 的异常机制并不是特别健壮，依赖它是不明智的。
另请注意，如果您捕获到异常，则意味着您的代码中的某些功能未完成。现在，这可能是一些琐碎的格式化事情，或者它可能是对您的整体算法至关重要的操作。任性地捕获和忽略异常可能会导致更大、更混乱的错误。
Usage of NSException in iPhone Apps的可能重复

标签： iphone ios objective-c

【解决方案1】：

不，您应该不要使用@catch 从异常中恢复并继续执行，就像什么都没发生一样。

有两个原因：

首先，您的代码中有一个错误。使用@catch 捕获异常并忽略它不是解决方法。您只是在解决一个症状，但错误仍然存在。

其次，iOS/Cocoa 编程明确不支持流控制异常——处理可恢复错误的异常。如果通过调用系统引发异常，则行为未定义。

如果您想了解更多详细信息，请在此处查看我的回答：Usage of NSException in iPhone Apps

【讨论】：

OSX 上的分布式对象和异常情况如何？
@Zaph 是的，DO 使用异常进行流量控制。这是该规则的少数例外之一。由于各种原因，它也几乎被弃用，以代替 XPC。

【解决方案2】：

在Apple's Documentation 中，你正好有这个例子：

[...] NSArray 的情况，例如，您应该始终检查数组的计数以确定尝试访问之前的项目数给定索引处的对象。 objectAtIndex: 方法抛出一个如果您提出越界请求，则例外，以便您可以找到开发周期早期代码中的错误——你应该避免在您交付给用户的应用中抛出异常。

【讨论】：

好的.. 谢谢.. 我会尽量避免抛出异常。 ...您能告诉我，如果我们用户尝试“objectAtIndex”的捕获机制，我们可以防止崩溃吗？
Apple 的文档说是的，你可以。我自己从来没有做过。
@user2459374 你不能。看我的回答。

【解决方案3】：

这不会坏

if([array count]>n)
obj =[array objectAtIndex:n]

【讨论】：

【解决方案4】：

您可以使用提供一个（或多个类似）方法的类别来扩展 NSArray。

- (id) saveObjectAtIndex:(NSUInteger)n {
    return (n < [self count]) ? [self objectAtIndex:n] : nil;
}

或者为此使用宏，这在性能方面可能是更好的方法。

坦率地说，我自己从来没有这样做过。为什么？如果我这样做了，那么我必须检查 nil 并做出相应的反应。因此，最后它与检查正值（如果索引变量已签名）并将其与计数属性进行比较然后对错误条件做出反应的工作量相同。从心理上讲，每次自己做都会引导我编写高质量的代码，并支持我对容错编码的认识。

【讨论】：