Re: My try/catch block isn't catching exceptions on 10.6
Re: My try/catch block isn't catching exceptions on 10.6
- Subject: Re: My try/catch block isn't catching exceptions on 10.6
- From: Mark Allan <email@hidden>
- Date: Fri, 27 Nov 2009 19:40:56 +0000
On 27 Nov 2009, at 1:10 am, Dave Keck wrote:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
After a cursory reading of your code it looks like you're dealing with
a threading issue involving myItemList or imminentList. Your comment
mentions "We don't really care if imminentList changes because the
dictionary object will always be there even if the contents aren't."
Does this mean you're modifying imminentList from one thread while
another is attempting to read from it? If so, you need a lock around
the reads and writes.
Isn't it the case that you only need locks around something if you
plan that it will be modified by more than one thread at a time, or if
you write to it in another thread and care that any read operation
will be predictable?
I *do* have locks around myItemList as this thread (and others) will
be modifying that array, but not around imminentList as I'll only be
reading it and I wanted to avoid a situation of over-locking things.
Two other threads do modify imminentList and I use locking in there to
safeguard those accesses. In this thread, if the key *is* in
imminentList, then that's fine and I don't need to do anything. If
it's not, that means either it was never in the list or that it was
just removed from under my feet, either way I'm not that bothered so I
take the safe option and add it to myItemList.
On 27 Nov 2009, at 12:22 pm, Jeremy Pereira wrote:
// We don't really care if imminentList changes because the
dictionary object will always be there even if the contents aren't.
Yes you do. NsMutableDictionary methods are not thread safe. If
you have other threads changing imminentList, while this thread is
inserting stuff, you'll need locking.
Other threads do change imminentList, but their access to it is
controlled via an NSLock. This thread doesn't insert anything into
imminentList at all, it merely checks for the existence of a
particular key. The only thing being inserted into is myItemList, and
I use NSLocks around anything that accesses that too.
Looking at the code, I don't think there is anything in it that
could throw an exception that you would want to handle. sending
objectToKey: to listToCopyFrom could raise an exception if it has
become shorter between the loop test and sending the message, but
that's a programmer error...
... and shouldn't happen because no other thread has access to
listToCopyFrom.
Sending setObject:forKey: could throw an exception if the NSNumber
is nil, but that would mean virtual memory exhaustion, what are you
going to do if you catch an out of memory condition? So I think
your try catch block is superfluous in this instance.
The catch block *is* superfluous. I only added it when I started
seeing these crashlogs come in as an attempt to pin down what was
happening. At least I now know why it catch block wasn't being
executed!
However, if there was an code that could throw an exception you
wanted to handle, your block currently leaks an object reference,
because the exception would bypass [listToCopyFrom release]. I tend
to use the following idiom:
Yes, I have @finally blocks elsewhere for that reason. Thanks
though. As I say, the try/catch was just something I was trying in a
development version of my app.
I'll add some locking logic around my reads from imminentList and use
an enumerator for listToCopyFrom to see if that makes any difference.
Thanks all for your advice,
Mark
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden