On Aug 21, 2015, at 20:18 , Rick Mann <[email protected]> wrote:
>
> Okay, so an Objective-C method that throws an exception...what happens?
This is part of the reason for avoiding calling the Swift feature “exceptions”.
What you throw in Obj-C is a NSException. It’s also an exception mechanism, but
it’s completely unrelated to the Swift error handling mechanism (and completely
unknown by the Swift runtime, except to the extent that the NSException class
is bridged like other Obj-C classes).
> Also, if the method of the call site is marked as "throws," does that mean
> the error will propagate out?
Yes, if it’s not caught. This corresponds to this Obj-C error-exit construct:
if (![someObject doSomethingAndReturnError: outError])
return NO;
That’s was I meant earlier about hiding the boilerplate. It’s less keystrokes
(and therefore hopefully clearer) to write:
try someObject.doSomething
though it means the exact same thing.
> Pity it's not a real exception mechanism.
Keep in mind that NSExceptions are (by convention) for programmer errors. Swift
errors are for flow control. Endlessly distinguishing between these two
unrelated cases has IMO long been a huge weakness of conventional exception
mechanisms, like the one in C#.
On Aug 21, 2015, at 20:03 , Rick Mann <[email protected]> wrote:
>
> how do you know this, was it covered in a WWDC video?
It was, also in the release notes, to some extent, but the key to it is
understand what Swift does when bridging a method declaration that has a
NSError** parameter. Once you see that, it’s “obvious” what’s going on under
the hood, because you know what it’s “really” doing on the Obj-C side.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
