*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil' crash when deleting non-persisted Core Data entities about tlindexpathtools HOT 4 CLOSED

The normal way to use TLIPT with Core Data is:

1. Don't specify an identifierKeyPath. By default, TLIPT identifies managed object by their objectID.
2. Call [NSManagedObjectContext obtainPermanentIDsForObjects:error:] on newly created objects to prevent the ID from changing when the object is saved.

Can you do that?

from tlindexpathtools.

Wowie. In short, yes, I could.

If in the eyes of TLIPT what I've done is somehow really stupid (which I don't think is, given that identifierKeyPath: is a part of the TLIPT API) then fair enough, I'll just stick to that opinionated use with Core Data.

The surprising crash behaviour is also seen in #22 — may be the thing that's more effective than investing any to fix the issue is just to provide more useful error messages.

I see TLIPT as a dependable component that connects data to my UI, and so to get crashes from it is really unsettling. When it works though it works beautifully, so thanks for that. =]

If only I had the time to delve into TLIPT's internals and philosophy + a workflow for submitting patches (from Cocoapods it's not trivial) I'd love to contribute back. For now I'm satisfied with the workaround.

That's not to say this issue doesn't need addressing!

from tlindexpathtools.

TLIPT provides multiple ways to identify objects. From the API documentation:

TLIndexPathDataModel needs to be able to identify items in order to keep an internal
mapping between items and index paths and to track items across versions of the data
model. It does not assume that the item itself is a valid identifier (for example,
if the item doesn not implement NSCopying, it cannot be used as a dictionary key).
So the following set of rules are used to locate a valid identifier. Each rule
is tried in turn until a non-nil value is found:

1. If identifierKeyPath is specified (through an appropriate initializer),
   the data model attempts to use the item's value for this key path. If the key
   path is invalid for the given item, the next rule is tried.
2. If the item is an instance of TLIndexPathItem, the value of the identifier
   property is tried.
3. If the item is an instance of NSManagedObject, the objectID property is used.
4. If the item conforms to NSCopying, the item itself is used.
5. If all else fails, the item's memory address is returned as a string.

The default behavior works in for the most common cases, but ultimately, the onus is on you to select an appropriate identifier. If you choose to use identifierKeyPath then you must ensure that the value doesn't change throughout the object's lifecycle.

I'm not sure there's an issue to fix here other than touching up the documentation.

from tlindexpathtools.

The point is, TLIPT shouldn't crash and burn if those conditions are not satisfied. A more helpful error, rather than documentation, is the fix.

i.e. with respect I don't think leaving codepaths to error states in the form of NSInvalidArgumentException thrown from [__NSArrayM insertObject:atIndex:] inside of TLIPT is a good idea, when all the user really needs to get going again is a pointer back to the documentation, or indeed, #31, this discussion.

#22 is related — the difference there is that it's not a crash that happens in TLIPT, but an eventual consistency problem in CollectionView (just as ugly, really).

For this one, onus may be on the user to select the correct identifier but I think you'll agree it's the onus of TLIPT not do throw NSArray index out of bounds exceptions under any circumstances. That's the responsibility of Foundation ;)

from tlindexpathtools.