Re: Exiting non-POSIX threads?
Re: Exiting non-POSIX threads?
- Subject: Re: Exiting non-POSIX threads?
- From: Ken Thomases <email@hidden>
- Date: Tue, 30 Jul 2013 10:20:21 -0500
On Jul 30, 2013, at 4:13 AM, Oleg Krupnov wrote:
>> 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.
The fact that AppKit continues after catching an exception at the top level is not great behavior to be emulating. It often hides errors which would be revealed and fixed more promptly if they caused the app to crash.
> 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.
The point of asserts is to fail early and very noticeably. Terminating the process is good. The fact that Cocoa's asserts throw exceptions and, therefore, can be quietly absorbed by AppKit's main event loop is bad. Consider replacing your use of Cocoa asserts with custom asserts. See this, for example:
http://www.mikeash.com/pyblog/friday-qa-2013-05-03-proper-use-of-asserts.html
>> 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.
The difference is precisely between terminating the process versus terminating a single thread but keeping the process alive and attempting to use frameworks whose internals may be corrupted. Of course, the default behavior of terminating the process is safe. It's the way you're trying to deviate from that that's not.
>> All in all, what you're doing seems like a bad idea.
>
> Maybe but what is the right solution to this?
Let the app crash. Let the CrashReporter tell the user that it crashed. If you want to receive the crash report yourself, use an external watchdog process or collect the crash report file on next launch.
Regards,
Ken
_______________________________________________
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