This is a fix for #19. These sanity checks are to replicate behavior of NSMutableDictionary methods removeObjectForKey: and removeObjectForKeys: which are documented to raise no exception for keys that do not exist.
This pull request also changes the behavior of these related methods to follow the same spirit:
removeLastEntryremoveEntryWithObject:removeEntryWithKey:removeEntryWithObject:pairedWithKey:removeEntry:removeEntryWithObject:inRange:removeEntryWithKey:inRange:removeEntryWithObject:pairedWithKey:inRange:removeEntry:inRange:removeEntryWithObjectIdenticalTo:removeEntryWithObjectIdenticalTo:inRange:removeEntriesWithObjectsInArray:removeEntriesWithKeysInArray:
Of these, I would regard only the changes to removeLastEntry and the inRange methods to be debatable as to whether they should always silently return vs generate a range error, though in case of the inRange methods, when the range is out of bounds and not when the entry is not present. In all of those cases, I'll argue that its extra code that needs to be written to generate these exceptions rather than removing the code that this pull request adds.
This pull request does not change the behavior of removeEntryAtIndex: or removeEntriesAtIndices:, these still raise an range exception like the NSMutableArray method removeObjectAtIndex: does.
This is a fix for #19. These sanity checks are to replicate behavior of
NSMutableDictionarymethodsremoveObjectForKey:andremoveObjectForKeys:which are documented to raise no exception for keys that do not exist.This pull request also changes the behavior of these related methods to follow the same spirit:
removeLastEntryremoveEntryWithObject:removeEntryWithKey:removeEntryWithObject:pairedWithKey:removeEntry:removeEntryWithObject:inRange:removeEntryWithKey:inRange:removeEntryWithObject:pairedWithKey:inRange:removeEntry:inRange:removeEntryWithObjectIdenticalTo:removeEntryWithObjectIdenticalTo:inRange:removeEntriesWithObjectsInArray:removeEntriesWithKeysInArray:Of these, I would regard only the changes to
removeLastEntryand theinRangemethods to be debatable as to whether they should always silently return vs generate a range error, though in case of theinRangemethods, when the range is out of bounds and not when the entry is not present. In all of those cases, I'll argue that its extra code that needs to be written to generate these exceptions rather than removing the code that this pull request adds.This pull request does not change the behavior of
removeEntryAtIndex:orremoveEntriesAtIndices:, these still raise an range exception like theNSMutableArraymethodremoveObjectAtIndex:does.