Re: Blocks vs. life, the universe and everything
Re: Blocks vs. life, the universe and everything
- Subject: Re: Blocks vs. life, the universe and everything
- From: Dave Zarzycki <email@hidden>
- Date: Sat, 15 Oct 2011 10:15:32 -0700
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 (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
>
> -- Jean-Daniel
>
>
>
>
> _______________________________________________
>
> 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
_______________________________________________
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