Re: How to avoid warning with objc_msgSend
Re: How to avoid warning with objc_msgSend
- Subject: Re: How to avoid warning with objc_msgSend
- From: Shawn Erickson <email@hidden>
- Date: Tue, 5 Oct 2004 11:55:28 -0700
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden