On Oct 14, 2011, at 11:44 PM, Jean-Daniel Dupas wrote:
>
> Le 15 oct. 2011 à 01:45, Quincey Morris a écrit :
>
>> On Oct 14, 2011, at 14:27 , Greg Parker wrote:
>>
>>> Do you actually use exceptions in your code, or do you follow the Cocoa
>>> convention that exceptions are for programmer error only? If you don't use
>>> exceptions, then you can omit any try blocks and let the uncaught exception
>>> handler log the failure and kill the process.
>>
>> No, I don't use exceptions in my own code at all, except for throwing some
>> inconsistency exceptions if an assert-like sanity check fails.
>>
>> All I want is for exceptions to break at my debugger breakpoint, or (when
>> not debugging or not stopping at the breakpoint) get logged the way they
>> have done so far.
>>
>> My concern was because of statements like this (in the GCD Reference):
>>
>>> Important: GCD is a C level API; it does not catch exceptions generated by
>>> higher level languages. Your application must catch all exceptions before
>>> returning from a block submitted to a dispatch queue.
>>
>> There's that "must" with no escape clause. Somewhere else (maybe in the
>> NSOperation Class Reference), there was something about not re-throwing
>> exceptions. I came away with the impression that the exception object itself
>> was not guaranteed to be valid after the operation/block exited, so that
>> relying on something outside that context to log it was dangerous.
>>
>> As an aside, TBH, I've never seen any evidence that uncaught (by my code)
>> exceptions lead to the process being killed. Typically, the process just
>> continues after logging a message. Maybe that's because I'm typically
>> running from Xcode so via the debugger, but I don't know that exceptions
>> (like a NSArray index out of bounds exception) kill the app on customer Macs
>> either.
>>
>
> I think this is because NSApp (or other parts of the framework) takes care of
> exceptions and try to prevent crash.
>
> You can try to run the following test to see what append when an exception is
> never caught:
The reason why that wording exists in the GCD documentation is the
"dispatch_sync" case and not really the async case. In other words, don't rely
on the following having predictable behavior:
@try {
dispatch_sync(some_queue, ^{
@throw @"anException";
});
} …
The reason for this is because dispatch_sync() doesn't promise whether the
block is run on the local thread or not.
davez
>
> ------
> #include <dispatch/dispatch.h>
> #import <Foundation/Foundation.h>
>
> int main(int arcg, char **argv) {
> dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,
> 0), ^{
> @throw @"Hello Exception";
> });
> sleep(2);
> NSLog(@"I'm still alive.");
> return 0;
> }
> -----
> 2011-10-15 08:41:29.414 test[28459:1603] *** Terminating app due to uncaught
> exception of class '__NSCFConstantString'
> terminate called throwing an exceptionAbort
>
>>> From the Concurrency Programming Guide:
>>> "If your block creates more than a few Objective-C objects, you might want
>>> to create your own autorelease pool to handle the memory management for
>>> those objects. Although GCD dispatch queues have their own autorelease
>>> pools, they make no guarantees as to when those pools are drained. However,
>>> if your application is memory constrained, creating your own autorelease
>>> pool allows you to free up the memory for autoreleased objects at more
>>> regular intervals."
>>
>> That's what I was looking for. My eyes must have glazed over when I was
>> reading that section.
>>
>> Thanks, this has been a big help.
>>
>>
>> _______________________________________________
>>
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
>>
>> This email sent to devli...@shadowlab.org
>
> -- Jean-Daniel
>
>
>
>
> _______________________________________________
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/zarzycki%40apple.com
>
> This email sent to zarzy...@apple.com
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
