Re: Can anyone confirm this IB Bug?
Re: Can anyone confirm this IB Bug?
- Subject: Re: Can anyone confirm this IB Bug?
- From: "Adam R. Maxwell" <email@hidden>
- Date: Sat, 02 Aug 2008 12:03:15 -0700
On Aug 2, 2008, at 11:08 AM, Jonathan Dann wrote:
Hi all,
I recently made an IBPlugin for one of my custom controls, which I
linked to my own framework. The framework had an NSArray category
with the method, -firstObject. When trying to run IB it kept
crashing before loading any of my custom control's code, the stack
trace showed that my -firstObject method was getting called (and not
by me).
Here's my implementation
- (id)firstObject;
{
return (id)CFArrayGetValueAtIndex((CFArrayRef)self, 0);
}
Which will raise an exception if the array has no elements. What I
think was happening is that somewhere in IB or InterfaceBuilderKit a
-firstObject method had been defined that returned nil when the
array was empty, so when my method was called, the caller was
expecting a method that *could* return nil. Am I right in my
diagnosis?
Ah, the joy of debugging categories :). This sounds likely, but you
could implement a +load or gcc constructor method in your category and
see if class_getInstanceMethod() returns a non-NULL method before your
category is loaded. Or class-dump InterfaceBuilderKit as I just did
and see that it has a pretty huge NSArray category that includes -
firstObject.
In my mind such a method should raise for index out of bounds, and I
shouldn't insulate myself in framework code from attempting to
access out of bounds. It has caused me to refactor a bunch of my
code that called my -firstObject method; nothing big, just annoying
as I'd used it a lot.
FWIW, I implemented a -firstObject method as well, but it returned nil
if the array was empty; to my mind, that fits better with the
semantics of -lastObject, especially for nested message sends. If
you're going to raise a range exception, I don't see any benefit over
using objectAtIndex:0 directly.
--
Adam
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden