On Friday, February 15, 2008, at 09:18AM, "John Stiles" <email@hidden> wrote:
>Bill Bumgarner wrote:
>> On Feb 15, 2008, at 8:49 AM, Chris Ryland wrote:
>>> What if you're using GC (and wrapping non-Cocoa things with
>>> *MakeCollectable())--is it then safe to use exceptions through Cocoa
>>> frames?
>>
>> No; it isn't limited to memory management issues. There may be any
>> number of bits of teardown / cleanup code that will be skipped as the
>> exception passes over it.
>That's always been my problem with exception handling in general. When
>everything is working fine, it's great and makes code look simpler. When
>a problem actually occurs, I think understanding the flow of control is
>extremely difficult if you aren't intimately familiar with the code base.
As a concrete example, this bit us when converting an app to use the NSDocument saving methods in 10.4 that use NSError** parameters. In 10.3 and earlier, we had been throwing exceptions and using them to bubble an informative error back up to the user for a lower-level save problem (string encoding conversion), but exceptions and NSError** do not mix.
It's really easy to throw an exception that keeps you from initializing an error pointer properly, and when you or AppKit try an use a garbage error, bad things happen...most of the time. The most stable solution was to eliminate exceptions and use NSErrors; this led to more code (NSErrors are annoyingly messy to create), but with far fewer problems.
--
adam
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
