Thanks Ken, > However, you're not supposed to let exceptions escape from blocks which you > submit to dispatch queues. That's documented in the link I gave in my > previous reply.
Yes, thanks for pointing it out, but let me note that this is not consistent with other parts of the AppKit. When an exception happens in the main thread, it is logged to the console and quietly absorbed without any additional action on my part. Now if the exception happens in a non-main thread, I am obliged to catch it or otherwise the app will be instantly terminated. This is inconsistent. I may not be using or even expecting any exceptions in the thread, but merely use some NSAssert's and want to report logical errors in my code. Putting explicit @try/@catch in every thread with NSAssert's seems like an overkill or even something I should not rely upon, because I want to write a catch-all for problems, including my own bugs, such as forgetting to wrap the thread in @try/@catch. > If you exit a thread that you don't own, you may screw up your app's ability > to present a dialog. Perhaps AppKit relies on that thread. Perhaps the > thread held a crucial resource and other threads will deadlock when they try > to access it. I'd disagree. This thread has already crashed and its exception was not caught, and so the thread is about to be terminated with or without my intervention. Killing it myself would hardly produce any side effects. I just want to prevent the entire app from termination and so far it seems darn impossible. > All in all, what you're doing seems like a bad idea. Maybe but what is the right solution to this? _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
