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 (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
