fix block may not be called

[xinjixjz]

Block may not be called when the user sends message to TMCache
instance, which will cause some problems.

[irace]

At first glance this doesn’t look like something we’d want to add. Can you explain what problems this fixes?

[xinjixjz]

1. Theoretically, we should call the block in every condition branches, because we should notify caller that the work has been done;
2. If user's some requirements depend on setObject:forKey:block block callback (but object or key is nil), then the block will never be called, which will cause some problems.
3. For example:

- (void)deadLockMethod
{
    __block id objectForKey = nil;
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);

    // user should wait the signal, but the key is nil and then block will never be called.
    [[TMCache sharedCache] objectForKey:nil block:^(TMCache *cache, NSString *key, id object) {
        objectForKey = object;
        dispatch_semaphore_signal(semaphore);
    }];

    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
}

[irace]

Passing a nil input sounds like programmer error to me. I think it’s something that should be checked for in userspace using assertions, rather than something that the library includes code to explicitly support.

Additionally, your example above is a bit too contrived to be compelling, as you wouldn’t use a semaphore to synchronize TMCache’s asynchronous APIs when it already provides synchronous alternatives for you.

[xinjixjz]

It is just a example, my point is library should consider the exception input, and the asynchronous APIs should notify caller in all conditions including exception conditions.
Additionally, in the synchronous APIs, the key and object will be set to nil in other thread and block will never be called, which will cause deadlock.
Any way, I think a robust library should consider exception input!

[lhyhsx]

@xinjixjz 这个提交挺好啊！他不给你合并，可惜了。