On July 30, 2013 at 12:04:44 AM, cocoa-dev-requ...@lists.apple.com
(cocoa-dev-requ...@lists.apple.com) wrote:
Message: 5
Date: Mon, 29 Jul 2013 12:54:26 +0300
From: Oleg Krupnov <oleg.krup...@gmail.com>
To: Steve Sisak <sgs-li...@codewell.com>
Cc: Cocoa-Dev List <cocoa-dev@lists.apple.com>
Subject: Re: Exiting non-POSIX threads?
Message-ID:
<cak83q-dwvfcwevz3mbh-yw2vshsfkz7vhhabrti9umqnh_u...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks for your answer, Steve, but the problem remains.
In my case, the exception has already been thrown inside the block and
I cannot catch it or modify it in any way in my handler. I'm basically
writing an uncaught exception handler. My app should show a crash
report window and then terminate itself.
Shortest path in this case may be to wrap dispatch_async() and pass a block
which executes the block parameter (currently passed to dispatch_async()) but
this added block introduces your exception handling. Be sure to copy the block
parameter, as dispatch_async() would.
Remember that exceptions originating from Cocoa APIs are generally
nonrecoverable (C++ implementations OTOH are generally designed to be safe to
catch and resume -- recoverable without leaking resources or leaving them in
potentially invalid states).
Assume killing threads is never an option ;) Just let them exit naturally so
that all implementations within that context may conclude what they are in the
process of executing. Sometimes that means you must choose (or design) more
robust implementations.
So when you catch that halting exception, then you can add some work to the
main run loop (e.g. to present the alert). You should then suspend the thread
which handled the exception (until your process is exited from the other thread
after the alert you mentioned was presented) to avoid returning control flow to
the implementation/queue which executed your block. Make sure your presentation
is quick and always exits, and avoid creating autoreleased objects in the
suspended thread (the pools will not be drained).
Of course, if it's your API that throws nonrecoverable exceptions you should
just use another mechanism for error handling to avoid all the above (and
perhaps recover gracefully).
_______________________________________________
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
