On Thu, Aug 14, 2008 at 5:45 AM, Uli Kusterer <[EMAIL PROTECTED]> wrote: > On 14.08.2008, at 12:58, Georg Seifert wrote: >> >> is it recommended to use @try .. @catch blocks as flow control like it is >> used in Python. They say explicitly to use it rather than do a lot of test >> before just try if it works to look after it only if it fails. > > > Apple's stance on exceptions so far has been that, with the exception of > some proxy objects (e.g. Distributed Objects), they should be used in Cocoa > for programming errors only. Otherwise, you're supposed to return a BOOL, or > an NSError, e.g. via a reference parameter, if more detailed failure info is > needed. > > Whether I consider that good or bad, it's what Apple recommend.
Yes, see <http://developer.apple.com/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/chapter_4_section_4.html#//apple_ref/doc/uid/TP40001806-CH204-SW6>. Regardless of merit, this is the Cocoa idiom. Also, a method only returns an NSError (as opposed to BOOL or nil) if the thing that went wrong is something that the user should be told about. No "error -9" here, these are user-presentable via presentError: and friends. The docs above cover it. Last, the frameworks themselves are written in the style recommended by the docs above. They do _not_ have @try @catch all over the place, they leave exception handling up to NSApplication at the top of the stack (for the most part). So, if you throw exceptions through framework code, you're likely to see memory leaks, and worse if you're unlucky. -Ken Cocoa Frameworks _______________________________________________ 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 [EMAIL PROTECTED]
