I have a custom table view in my app. I have implemented the \"Load More\" feature to the table which loads 25 rows at a time. The problem is after loading 2 times the app crash
Messages to nil that return structs of structs can return undefined values in the inner struct.
In practical terms, this means that getting the frame
from a nil
UIView
can return undefined values in the size
field of the frame
. This bug just bit me and I was surprised.
I had this same exact error because instead of writing
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { ... }
i wrote:
- (NSInteger)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { ... }
(notice the return value). Hope this helps somebody.
For me it was caused by the toView in this code being nil:
[UIView transitionFromView:self.fromView
toView:self.toView
duration:0.6
options:(currentPage > toPage ? UIViewAnimationOptionTransitionCurlDown : UIViewAnimationOptionTransitionCurlUp)
completion:^(BOOL finished) {
if (finished) {
}
}
The simple answer:
Returning a NaN from any of the height related delegate methods causes this error.
tableView:heightForRowAtIndexPath:
tableView:heightForHeaderInSection:
tableView:heightForFooterInSection:
etc..
There may be other ways to produce this error but if you're working with UITableView--check this first!
The stack trace looks like the UITableView is busy layouting the visible cells when the exception occurs. Since the position of a cell seems to be set to a NaN
value one has to ask how this can happen.
Assuming there's no bug in the UITableView layout code, the only way this can happen is that you implement tableView:heightForRowAtIndexPath:
in your table view delegate and return a bad height (or one of the according header or footer methods).
Edit to pinpoint the exact cause of the exception:
I assume you calculated the height of the cell from the geometric size of a string (using UIStringDrawing
's -[NSString sizeWithFont:]
). When you send a message to a nil value, the return value usually is nil, 0, NO, or whatever value is represented by an all-bits-zero word.
For a method that returns a struct (as sizeWithFont:
) this is not true. The returned struct is not initialized at all, containing random values for its elements.
In your case, you probably used one of the uninitialized elements of the CGSize struct, which later turned out not to be a valid IEEE 754 floating point value.
Addendum: Since clang 3.0 the structs returned from messages are initialized to {0} (all bits zero). So above problem should not happen any more.