Open Radar

 
Summary:

There is not enough information about -[UITableView dequeueReusableCellWithIdentifier:forIndexPath:], and using it throws exceptions.

Steps to Reproduce:

As usual, in the table view's data source cellForRowAtIndexPath method, use dequeueReusableCellWithIdentifier:forIndexPath: where one would normally use dequeueReusableCellWithIdentifier:

If you forgot to register a class or nib, expect an exception.
(This behavior is documented).

If you pass nil for the index path parameter, expect an exception, but don't get one!

If you pass an index path that is not known to the table view, don't expect an exception but get one anyway!
> request for rect at invalid index path (<NSIndexPath 0x8361f40> 2 indexes [0, 0])

This last exception is a "deal breaker" for this method - it makes unit testing a table view data source 10x harder then it needs to be.

Expected Results:

The only real mention of the index path argument is this snippet from documentation - 
The index path specifying the location of the cell. The data source receives this information when it is asked for the cell and should just pass it along. This method uses the index path to perform additional configuration based on the cell’s position in the table view.

Digging into the UITableView.h header we get this tidbit - 
// newer dequeue method guarantees a cell is returned and resized properly, assuming identifier is registered

Actual Results:

Based on the documentation available to me, I don't understand why I'd use this method over the older dequeueReusableCellWithIdentifier:

Regression:

Notes: