The contract for MyProtocol is that if you don't recognize 'token',
you send -handleToken: to super. If no superclass implements
-handleToken:, then a runtime exception is correctly generated since
no one could handle the token. (This is exactly the same as KVO's
ClassB's implementation of -handleToken: triggers the "'ClassA' may
not respond to 'handleToken:'" warning on the call to super:
> No it isn't. If you are explicitly sending messages that a class does not respond to then an informal protocol is exactly what you want.
I consider informal protocols as workarounds created before formal
protocols supported @optional methods, which is why I avoided option
3. Am I wrong in that assessment?
> Note that there is nothing stopping you from using both a formal and informal protocol, if you wish for explicit testing.
I ended up doing something close to that; I still have the mentioned
MyProtocol, but also MyCategory on NSObject that implements MyProtocol
as the base case, by simply throwing a custom exception as you
describe. A much cleaner approach indeed, and it gets rid of the
> Using these exceptions is very bad style for several reasons:
> 1) Exceptions in Objective-C are intended to indicate programmer error and are very slow. Using them for a recoverable error is bad.
> 2) You are overloading the meaning of an exception, making it difficult to distinguish between a real error and this error.
> 3) Code that assumes 1) (i.e. most Cocoa code, including code compiled with ARC enabled) will leak memory if it's in any intervening stack frames.
I consider my use of exceptions to be in-line with what you describe:
some programmer made an error and isn't handling a token as they