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:
------
#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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
