• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: exceptions, threads & NSLock
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exceptions, threads & NSLock


  • Subject: Re: exceptions, threads & NSLock
  • From: "Clark Cox" <email@hidden>
  • Date: Sat, 18 Mar 2006 07:47:41 -0500

If you don't need to do anything with the exception itself, you can
omit the "catch" block:

[myLock lock];
@try {
// some stuff that may throw exceptions
}
@finally {
[myLock unlock];
}

Or, if you can get away from using NSLock's altogether (i.e. you're
only calling -lock and -unlock, and you don't need any other NSLock
methods like -tryLock or -lockBeforeDate:), you can just use
@synchronized:

@synchronized(self)
{
  //Some stuff that may throw exceptions
}


On 3/13/06, John McLaughlin <email@hidden> wrote:
> Hi All,
>
> I'm a bit of a newb at both Objective C & Mac OSX programming so forgive me
> if this is already well covered somewhere (I searched these archives and
> looked through the docs and haven't found a satisfying answer)
>
> I've got an app which launches threads for some lengthy background type
> task... Since there are potentially multiple threads being launched I wanted
> to protect against a problem by using NSLock
>
> My original implementation was
>
> [myLock lock] ; // myLock is of type NSLock *
>
> // Some stuff here that may throw an exceptio
>
> [myLock unlock];
>
> This actually seems to be working fine but the other day it occured to me
> that it's possible for a situation where the threads stop functioning if an
> exception's thrown between the lock & unlock
>
>
> I went ahead an added exception handling like this
>
> [myLock lock];
> @try {
> // some stuff that may throw exception
> }
> @catch {NSException *exception) {
>
> @throw (exception)
> }
>
> @finally {
> [myLock unlock];
> }
>
> I think the example above does more what I want... It gurantees (I think?)
> that the lock is always unlocked regardless of what bad thing happens in my
> try code.
>
> My questions:
>    1) Did I get this right and do I need to use exception handling in this
> kind of situatio
>    2) I believe for modern code the preferred approach is @try not
> NS_EXCEPTION, correct?
>    3) My intent is that i actually want any exceptions to be thrown to a
> higher level , I just want to guarantee my 'Finally' code runs in all
> cases... Do I have this behavior?
>
>
> Thanks
>
> -John
>  _______________________________________________
> 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
>


--
Clark S. Cox III
email@hidden
My CV/Resume:
http://homepage.mac.com/clarkcox3/files/Resume.pdf
http://homepage.mac.com/clarkcox3/files/Resume.html
 _______________________________________________
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

References: 
 >exceptions, threads & NSLock (From: "John McLaughlin" <email@hidden>)

  • Prev by Date: Application Plugins
  • Next by Date: Re: which cocoa objects to dealloc ?
  • Previous by thread: exceptions, threads & NSLock
  • Next by thread: How to find the name of the tab view item if you have one of its sub-views(sub-sub-views)?
  • Index(es):
    • Date
    • Thread