When to use introspection

If it should be one thing and it isn't, then depending on the severity of the issue you have options such as:

Throw an exception.
Pop up an alert

... I can't think of much else you could do, if you wanted to do anything. I suppose you could trash the array and start from scratch putting what you want into it...

 

As in many things, it all depends.

If a method has a contract and the contract is violated then you can assert, which throws an exception and crashes your app. This is the idiom followed by Apple. They call it "programmer error" and it results in the widely seen SIGABRT error. It's a reasonable policy that should result in higher quality code.

Learn to use the NSAssert() macro. It's another way to test your code. It's similar to unit testing in some ways.

Introspection is completely orthogonal to this however. In general I prefer to have designs that avoid introspection except maybe for respondsToSelector with delegates. I would prefer to have a requirement for the types of objects that are found in a given container. So if you have a dictionary that has a key/value pair where the key is @"name" the value must be a string. It can't be a number or some other random object. I probably don't have code that verifies this though. Most likely if the name isn't a string and the code tries to use it as a string there will be an assertion failure. If you want to use NSAssert() to verify the kind of objects found in your containers matches your contract that might make sense. In most cases I'd find that to be over the top though.

I think maybe you don't know what introspection means:

http://en.wikipedia.org/wiki/Introspection_(computer_science)

 

Objective-C already does that, to some extent. If you try to send a message to an object that doesn't have a method, then the objc_msgSend fails.

You can add a function to catch uncaught exceptions:
https://developer.apple.com/library...ns.html#//apple_ref/doc/uid/20000056-BAJDDGGD


If you're looking for more type-safety than that supplied by other means, you can wrap an NSDictionary or NSMutableDictionary in a class of your own making, and enforce the type-safety there. You shouldn't do this by subclassing, because the collection classes are class clusters.

A class wrapper is also a better design than sprinkling a bunch of type-checks through the code. The reason is similar to why magic numbers are bad: Don't Repeat Yourself. A class is a centralized locus of behavior, so if (when) it needs to be changed, it can be done in one place and all others get the change automatically.


By the way, I don't really see the purpose of your posted code. If the 'sender' object isn't an NSMutableDictionary, the method doesn't complete its task. It doesn't roll back what it already did, either, possibly leaving the program in an inconsistent state (cascade failure likely). This can be a bad idea, because it hides fundamental errors.

When testing, I would much rather know about such fundamental errors, rather than be writing code that masks them. Masking errors kinda defeats the purpose of test-driven programming,

If some piece of code can't work with objects other than a specific type, then it should stop working in an obvious way, such as by failing an assertion. It should NOT quietly accept an unusable parameter and quietly do only part of what its entire task should be.

Please explain what you mean by "at the front end".

 

In my experience with ios development, Ive found that really the only use ive had for introspection is with delegates/protocols. Its important for "optional" delegate methods.