Re: @try @catch
Re: @try @catch
- Subject: Re: @try @catch
- From: "Ken Ferry" <email@hidden>
- Date: Thu, 14 Aug 2008 18:26:42 -0700
On Thu, Aug 14, 2008 at 5:45 AM, Uli Kusterer
<email@hidden> 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 (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