Re: How to avoid warning with objc_msgSend

FROM : Shawn Erickson
DATE : Tue Oct 05 20:55:28 2004

On Oct 5, 2004, at 11:28 AM, David Elliott wrote:
>> Then do this:
>>
>> id aView = GetNSView();
>> NSRect *rects = NULL;
>> int rectCount = 0;
>> if ([aView respondsToSelctor:@selector(getRectsBeingDrawn:count:)]) {
>>     [aView getRectsBeingDrawn:&rects count:&rectCount];
>> }
>>
>> That obviously won't cause a runtime warning on 10.2 and lower. It'll
>> cause a compile-time warning, removing that would be an exercise for
>> the reader (hint: define a protocol, but this is really bad practice
>> as those methods aren't really implemented and thus the warning is
>> perfectly valid).
>>

> Right.  I could have used a protocol but I didn't see the point when I
> could just as easily call objc_msgSend myself and get (AFAICT) the
> exact same result.
>
> The problem I have is not that the compiler issues a warning (it
> doesn't, obviously) but that the runtime on 10.2 issues a warning.  I
> would have thought that the whole point of catching the exception is
> to avoid any ill effects that may happen from calling an unimplemented
> method.  And indeed, without catching the exception the app will
> crash.  But even when I do catch it it emits a console warning which
> IMHO is ridiculous.


Note that exceptions are just that exceptions, they really should not
be used as a normal part of program flow (you expect them to happen) as
you are attempting to do (some aspects of Java for example push using
exceptions in normal flow branching much more then Cocoa does). So the
runtime is logging an exceptional case that is being hit so that a
developer can fix the issue. So I don't see what it is doing as being
ridiculous given the general use of exceptions in Cocoa.

> I had thought about using respondsToSelector though it seemed there
> ought to be a way to have it attempt to call the method and in the
> event that it is not implemented simply ignore the error rather than
> checking if it is implemented each time before calling the method.
>
> If there is no way to silence the runtime warning I have two choices:
> 1) use the above method and see if it's implemented before calling it
> 2) just remove the code since most apps probably won't benefit from
> this optimization anyway.


The normal and Apple recommend way is to use respondsToSelector on the
object or better yet set a global boolean by asking if the class
supports the needed selector (instancesRespondToSelector:) then check
that boolean before attempt to call it.

Anyway Glenn outlined a good way of doing this transparently to most of
your code in his email (implement the missing method in category that
you trigger the loading of on older systems and have the method simply
do nothing or simulate the missing functionality depending on what
makes sense).

You could get tricky (not that I recommend this) and try to override
-doseNotRecognizeSelector and then have this sub-class pose as NSObject
filtering out exceptions that you don't want sent. Likely this has at
least a few issues...

Of course if you have ideas / opinions about how things should be
handled (for example allow one to disable such messages from being
logged programatically) then let Apple know
<http://developer.apple.com/bugreporter/>.

-Shawn