Bounds checking in indexed accessor methods

  • What are people's thoughts on performing bounds checking in indexed
    accessor methods?

    For example, see the sample methods pasted below: given an
    NSMutableArray instance variable called "sockets", you can generate
    "simple" indexed accessors that don't perform any bounds checking, or
    "robust" accessor that do perform bounds checking (these method
    implementations generated using Accessorizer:  http://
    www.kevincallahan.org/software/accessorizer.html).

    If I were just accessing the NSMutableArray directly I would expect
    it to throw an exception if I used an out-of-bounds index. This would
    hopefully draw my attention to a programming error somewhere in my
    code which I could then fix. So I am tempted to think that "simple"
    accessors are the way to go. Are there any arguments for why I should
    use "robust" indexed accessors then?

    I did find this old post by Scott Stevenson (http://
    www.cocoabuilder.com/archive/message/cocoa/2004/3/3/100753) in which
    he says:

    > I've encountered situations where the array controller will request
    > index 2147483647, which I would guess is the unsigned (rollover)
    > version of -1. I'm guessing this is some sort of bug in the
    > frameworks.

    Anyone else seen this possible bug in recent versions of Mac OS X? In
    my own code (custom class with NSMutableArray instance variable,
    bound to NSTableView via an NSArrayController) I've put in logging
    statements to see when out of range values might be generated and I
    don't ever see any such values (neither adding nor removing rows, nor
    dragging and dropping to rearrange their order).

    Any other thoughts?

    Anyway, here are the accessors:

    "simple"

    - (unsigned int)countOfSockets
    {
        return [[self sockets] count];
    }

    - (id)objectInSocketsAtIndex:(unsigned int)index
    {
        return [[self sockets] objectAtIndex:index];
    }

    - (void)insertObject:(id)anObject inSocketsAtIndex:(unsigned int)index
    {
        [[self sockets] insertObject:anObject atIndex:index];
    }

    - (void)removeObjectFromSocketsAtIndex:(unsigned int)index
    {
        [[self sockets] removeObjectAtIndex:index];
    }

    - (void)replaceObjectInSocketsAtIndex:(unsigned int)index withObject:
    (id)anObject
    {
        [[self sockets] replaceObjectAtIndex:index withObject:anObject];
    }

    "robust"

    - (unsigned int)countOfSockets
    {
        return [[self sockets] count];
    }

    - (id)objectInSocketsAtIndex:(unsigned int)index
    {
        id mySockets = [self sockets];
        unsigned int socketsCount = [mySockets count];
        if ( socketsCount == 0 || index > (socketsCount - 1) ) return nil;

        return [[[mySockets objectAtIndex:index] retain] autorelease];
    }

    - (void)insertObject:(id)anObject inSocketsAtIndex:(unsigned int)index
    {
        id mySockets = [self sockets];
        unsigned int socketsCount = [mySockets count];
        if (index > socketsCount) return;

        if (anObject) [mySockets insertObject:anObject atIndex:index];
    }

    - (void)removeObjectFromSocketsAtIndex:(unsigned int)index
    {
        id mySockets = [self sockets];
        unsigned int socketsCount = [mySockets count];
        if ( socketsCount == 0 || index > (socketsCount - 1) ) return;

        [mySockets removeObjectAtIndex:index];
    }

    - (void)replaceObjectInSocketsAtIndex:(unsigned int)index withObject:
    (id)anObject
    {
        id mySockets = [self sockets];
        unsigned int socketsCount = [mySockets count];
        if ( socketsCount == 0 || index > (socketsCount - 1) ) return;

        [mySockets replaceObjectAtIndex:index withObject:anObject];
    }
  • On Oct 7, 2006, at 5:25 AM, Mailing list subscriptions wrote:

    > What are people's thoughts on performing bounds checking in indexed
    > accessor methods?
    >
    > For example, see the sample methods pasted below: given an
    > NSMutableArray instance variable called "sockets", you can generate
    > "simple" indexed accessors that don't perform any bounds checking,
    > or "robust" accessor that do perform bounds checking (these method
    > implementations generated using Accessorizer:  http://
    > www.kevincallahan.org/software/accessorizer.html).
    >
    > If I were just accessing the NSMutableArray directly I would expect
    > it to throw an exception if I used an out-of-bounds index. This
    > would hopefully draw my attention to a programming error somewhere
    > in my code which I could then fix. So I am tempted to think that
    > "simple" accessors are the way to go. Are there any arguments for
    > why I should use "robust" indexed accessors then?

    It's really a personal choice.  What I do is the following:

    * If the array will have private accessors, I write things for
    speed.  This is especially so if the array will always be of fixed size.

    * If the array will have public accessors, I tend to add the error
    checking.  Although, when I do so, I use debug-build-only asserts
    that ultimately throw exceptions.

    > I did find this old post by Scott Stevenson (http://
    > www.cocoabuilder.com/archive/message/cocoa/2004/3/3/100753) in
    > which he says:
    >
    >> I've encountered situations where the array controller will
    >> request index 2147483647, which I would guess is the unsigned
    >> (rollover) version of -1. I'm guessing this is some sort of bug in
    >> the frameworks.
    >
    > Anyone else seen this possible bug in recent versions of Mac OS X?
    > In my own code (custom class with NSMutableArray instance variable,
    > bound to NSTableView via an NSArrayController) I've put in logging
    > statements to see when out of range values might be generated and I
    > don't ever see any such values (neither adding nor removing rows,
    > nor dragging and dropping to rearrange their order).

    That particular value is used by the constant NSNotFound.  I would
    look into cases where that value could flow through your system (e.g.
    where you call an API to do a lookup of an item that ends up not
    being in a collection)

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today