Re: Exiting non-POSIX threads?
Re: Exiting non-POSIX threads?
- Subject: Re: Exiting non-POSIX threads?
- From: "j.carlson" <email@hidden>
- Date: Tue, 30 Jul 2013 08:37:14 -0400
Subject: Re: Exiting non-POSIX threads?
From: Oleg Krupnov <email@hidden>
Date: Tue, 30 Jul 2013 12:13:38 +0300
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.
Ken's right. The side effects may be significant, and you shouldn't assume that it will not impact system/foreign implementations executing in that context (i.e. thread). When an exception is thrown, the program unwinds. This gives other implementations the opportunity to perform their cleanup, even though *your* implementation may not do anything meaningful when unwinding. Killing/exiting the thread at an arbitrary point in execution is more likely to leave other implementations in unspecified states. A (non-shared) int on the stack is not a concern, but what if your thread's autorelease pools were never drained or locked shared resources never unlocked?
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?
The easy way is to just not introduce exceptions into your Cocoa programs, and to design with appropriate error handling and recovery in mind. That also means preventing your implementation from doing something which would cause an API you call to throw. If you use an implementation which throws (e.g. C++), forbid that exception from entering your Cocoa implementations. Some Cocoa APIs throw, but those errors are generally nonrecoverable and you should not try to handle them (you could prevent them, if it is your error). This default 'works' for most projects.
Defending your implementation from anything that could possibly throw while being prepared to appropriately handle what *could* be thrown without context is futile at this abstraction level. If you really insist you should intercept this information and think you can do meaningful things with it or allow meaningful tasks on other threads to complete, another angle would be to specify the thread's NSAssertionHandler instance in the -[NSThread threadDictionary] (key: NSAssertionHandlerKey). However, there's not much good you can do here beyond noting the error for future presentation or your log for review and immediately exiting -- I would not bother forcing an alert through to the user on the dying process' main run loop.
_______________________________________________
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