> also, using setValue:forKey:, if value was nil it would call removeObjectForKey: instead of throwing an exception.

Huh. Did not know that. I guess we can toss this pull request out then.

But in general, I'm in favor of making errors more explicit, always. Anything that saves time tracking down a bug. So maybe we need to provide more error handling here in general.

> ... if what comes back is not a dictionary we fail silently at the moment. Would this be much different?

This is a prime example. You might not have any idea why your keychain values aren't sticking. Also I think it is slightly different - when setting a nil key/value on a dictionary, you always get an exception (which is good - it's programmer error). It should be up to the caller to catch those errors IMO rather than letting it silently fail. RZKeychain is really kind of a data structure abstraction, so it should make no promises about how it's going to handle bad data, just as the Foundation classes don't.

But I'm open to being convinced otherwise.