On Oct 14, 2011, at 14:27 , Greg Parker wrote: > Do you actually use exceptions in your code, or do you follow the Cocoa > convention that exceptions are for programmer error only? If you don't use > exceptions, then you can omit any try blocks and let the uncaught exception > handler log the failure and kill the process.
No, I don't use exceptions in my own code at all, except for throwing some inconsistency exceptions if an assert-like sanity check fails. All I want is for exceptions to break at my debugger breakpoint, or (when not debugging or not stopping at the breakpoint) get logged the way they have done so far. My concern was because of statements like this (in the GCD Reference): > Important: GCD is a C level API; it does not catch exceptions generated by > higher level languages. Your application must catch all exceptions before > returning from a block submitted to a dispatch queue. There's that "must" with no escape clause. Somewhere else (maybe in the NSOperation Class Reference), there was something about not re-throwing exceptions. I came away with the impression that the exception object itself was not guaranteed to be valid after the operation/block exited, so that relying on something outside that context to log it was dangerous. As an aside, TBH, I've never seen any evidence that uncaught (by my code) exceptions lead to the process being killed. Typically, the process just continues after logging a message. Maybe that's because I'm typically running from Xcode so via the debugger, but I don't know that exceptions (like a NSArray index out of bounds exception) kill the app on customer Macs either. > From the Concurrency Programming Guide: > "If your block creates more than a few Objective-C objects, you might want to > create your own autorelease pool to handle the memory management for those > objects. Although GCD dispatch queues have their own autorelease pools, they > make no guarantees as to when those pools are drained. However, if your > application is memory constrained, creating your own autorelease pool allows > you to free up the memory for autoreleased objects at more regular intervals." That's what I was looking for. My eyes must have glazed over when I was reading that section. Thanks, this has been a big help. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
