Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception support (was: Feeding NSUnarchiver bad data can cause crash)

On Jun 3, 2004, at 12:46 PM, Ondra Cada wrote:

On 3.6.2004, at 18:04, Shawn Erickson wrote:

... Either go @try, or ...

'Course, that's not why I write: do you understand the new directives?
Namely, do you happen to know

- how (in)compatible they happen to be with the NS_... macros?

I agree that Apple has been unclear on this. The documentation (as usual) seems to be geared toward new Cocoa developers, and glosses over backward compatibility concerns. When the feature first came out, there should've been a technote posted immediately covering this in a lot more detail.

Thus I ran my own tests a while back. Seems they're fully compatible. You can @throw an object and have it caught by NS_HANDLER, or -[NSException raise] and have it caught by @catch.

The major caveat is that @try/@catch etc requires runtime support in Foundation that is only present in 10.3 and later. If you use @try/@catch your app/bundle won't load on 10.2 and earlier.

- are they less or more efficient?

Haven't done any performance testing ... what I've heard is that the one is compiler-supported syntactic sugar for the other. Since they are so interchangeable that seems likely.

As for me personally, I try not to write code where I care how many thousands of exceptions I can throw per second. :-)

- what caveats there are mixin' them with NS_... macros? (seems with
@throw you can raise anything, but NS_HANDLER would suppose there's an
NSException subclass in localException, would it not?)

Whatever object you throw seems to get stashed into NS_HANDLER's localException. NS_HANDLER/NS_ENDHANDLER themselves do not reference localException in a way that requires it to be an NSException, or (as far as I can tell) an NSObject at all.

So it depends on the implementations of the handlers higher in the stack and whether they do anything with localException. That means for safety's sake you should probably always throw NSExceptions.

- which way is better for which situations?

For code that needs to run on pre-10.3 systems, you must use NS_HANDLER and [NSException raise]. This is non-negotiable ... the runtime support isn't there on 10.2 and earlier.

For code that can require 10.3 and later, I prefer @try/@catch/@finally for exception handling since the @finally clause makes it easier to write code that doesn't leak. Exception raising might as well be done with [NSException raise] since it's a convenient API, and is easy to break on in gdb. Don't throw non-NSExceptions unless you can guarantee that the handlers above you in the stack are prepared to deal with them.

You can view my test code at <http://homepage.mac.com/drewthaler/exceptions.m>.

drew

--
Drew Thaler
Recording Artist
Email/AIM: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Feeding NSUnarchiver bad data can cause crash (From: "Douglas A. Welton" <email@hidden>)
 >Re: Feeding NSUnarchiver bad data can cause crash (From: Shawn Erickson <email@hidden>)
 >Exception support (was: Feeding NSUnarchiver bad data can cause crash) (From: Ondra Cada <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.