Re: Exception support (was: Feeding NSUnarchiver bad data can cause crash)
Re: Exception support (was: Feeding NSUnarchiver bad data can cause crash)
- Subject: Re: Exception support (was: Feeding NSUnarchiver bad data can cause crash)
- From: Shawn Erickson <email@hidden>
- Date: Thu, 3 Jun 2004 10:08:42 -0700
On Jun 3, 2004, at 9:46 AM, Ondra Cada wrote:
do you understand the new directives? Namely, do you happen to know
- how (in)compatible they happen to be with the NS_... macros?
Don't know exactly. I believe that they are compatible however not
likely sensibly intermixed in the same code block, in a given block use
one or the other.
- are they less or more efficient?
Well in theory @try will be more efficient in the long run because of
how it is supported. It is supported at the compiler level so things
are directly injected as needed, they are not macro based. Apple is
panning to advance them as things they leverage get rework and
improved. Again I really haven't dug deep into it to see the difference
in the resulting code (given backward compatibility currently with
NS_DURING... it may not be much different).
- 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?)
Don't know.
- which way is better for which situations?
I would say that @try/@catch/@finally/@synchronize is always better
IMHO. They are cleaner/clearer in meaning/reading and they work with
each other well and things like returns, breaks, etc. in a code block.
Also it is nice to have the recursive mutex released for you
automatically on exiting a synchronize block even in the case of an
exception.
Perhaps I've overlooked something, but save for a short info along
lines of "are backward compatible with NS... macros, incompatible with
C++ exceptions" in the release notes I've found nothing on this
subject yet...
I do know that Apple folks would love to make the @try... stuff support
C++ exceptions directly without any extra work on our part. I cannot
find the email that stated this now but I believe it was on the
objective-c list a while back.
-Shawn
_______________________________________________
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.