1

I am new to iPhone,

Our Team created an App and uploaded to "AppStore", We integrated "Bug Sense" also.

Now our app got negative reviews because of crash, We are tested our App in iPhone/iPad 6.1.3

In my bug sense we got this report like below:

1st Error:

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

2nd Error:

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

Now IN my project i placed @try{ } catch blocks to the methods which uses "objectAtIndex" to prevent the crash,

and i placed the condition also i.e., if the array count is grater than "0" then only it will enter in to my condition which uses "objectAtIndex"

My question is, can we prevent the above errors crash by using @try, catch mechanism .

Thanks in Advance

Vinayak Kini
  • 2,919
  • 21
  • 35
user2459374
  • 13
  • 1
  • 3
  • 8
    Well, the best way to handle array bounds errors is to not get them -- write sound code in the first place and pre-check if there is any reason to be suspicious. You can catch the errors with try/catch in some cases, but the Objective-C exception mechanism is not particularly robust, and it's not wise to rely on it. – Hot Licks Jun 06 '13 at 11:48
  • 1
    Also note that if you catch an exception that means that some function in your code did not complete. Now, that may be some trivial formatting thing, or it may be an operation that is critical to your overall algorithm. Willy-nilly trapping and ignoring exceptions can lead to even bigger, messier bugs. – Hot Licks Jun 06 '13 at 16:09
  • possible duplicate of [Usage of NSException in iPhone Apps](http://stackoverflow.com/questions/4310560/usage-of-nsexception-in-iphone-apps) – bbum Jun 06 '13 at 17:08

4 Answers4

16

No, you should not use @catch to recover from exceptions and continue execution as if nothing happened.

For two reasons:

First, you have a bug in your code. Using @catch to catch the exception and ignore it is not a fix. You are simply addressing a symptom, but the bug remains.

Secondly, exceptions for flow control -- exceptions for handling recoverable errors -- is explicitly not supported in iOS/Cocoa programming. If an exception is thrown through a call to the system, the behavior is undefined.

If you would like more details, see my answer here: Usage of NSException in iPhone Apps

Community
  • 1
  • 1
bbum
  • 162,346
  • 23
  • 271
  • 359
  • What about Distributed Objects and exceptions on OSX? – zaph Jun 10 '13 at 15:32
  • 1
    @Zaph Yes, DO used exceptions for flow control. It was one of a handful of exceptions to the rule. It is also all but deprecated for a variety of reasons, in lieu of XPC. – bbum Jun 10 '13 at 20:06
2

In the Apple's Documentation, you have exactly this example:

[...] the case of an NSArray, for example, you should always check the array’s count to determine the number of items before trying to access an object at a given index. The objectAtIndex: method throws an exception if you make an out-of-bounds request so that you can find the bug in your code early in the development cycle—you should avoid throwing exceptions in an app that you ship to users.

Bruno Koga
  • 3,864
  • 2
  • 34
  • 45
1

This wont break

if([array count]>n)
obj =[array objectAtIndex:n]
Lithu T.V
  • 19,955
  • 12
  • 56
  • 101
0

You may extend NSArray with a category providing one (or a number of similar) methods. 

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

Or use a macro for that, which may be the better approach in terms of performance.

Frankly, I never did that myself. Why? If I did that then I had to check for nil and react on that accordingly. So in the end it is the same amount of work as checking for positive values (if the index variable is signed) and compare it with the count property and then react on the erroreous condition. Psycologically, doing it myself every time guides me writing quality code and supports my awareness for error tolerant coding.

Hermann Klecker
  • 14,039
  • 5
  • 48
  • 71