> On Aug 21, 2015, at 8:18 PM, Rick Mann <rm...@latencyzero.com> wrote: > >> On Aug 21, 2015, at 20:06 , Greg Parker <gpar...@apple.com> wrote: >> >>> On Aug 21, 2015, at 6:15 PM, Rick Mann <rm...@latencyzero.com> wrote: >>> >>>> On Aug 21, 2015, at 18:13 , Quincey Morris >>>> <quinceymor...@rivergatesoftware.com> wrote: >>>> >>>> I’d recommend you try to avoid calling the Swift side “exceptions”. It’s >>>> error handling, and although it’s not completely unlike exception handling >>>> in other (non-Obj-C) languages, it’s treacherous to confuse the two when >>>> dealing with Obj-C. >>> >>> Really? It sure seems to be precisely an exception, in that it's an >>> exception to the "normal" flow of control (e.g. return). Just because the >>> type of what's thrown is called "Error" doesn't change the fact that >>> they're conceptually exceptions (as opposed to, say, returning a boolean >>> true/false to indicate an error). >> >> We avoid the word "exception" for Swift's error handling. >> >> The fundamental feature of exception systems is that the call site need not >> do anything. If the call site does nothing, the exception automatically >> unwinds past it. There is no syntactic difference between a call site that >> may throw and a call site that will never throw. >> >> Swift's error handling is different: the possibility of error is explicit at >> the call site. Some people think this is better (no invisible execution >> paths) and some people think it is worse (too noisy). Either way the model >> is different enough that we don't call it exception handling. >> >> The fact that Swift's errors map to Objective-C NSError instead of >> Objective-C exceptions is another reason to avoid "exception". > > Okay, so an Objective-C method that throws an exception...what happens?
Swift makes no attempt to interact with C++/ObjC exceptions, so it will not be caught by Swift. Swift's generated code is not exception-safe, but I don't know precisely how unsafe it is. The process might halt in std::terminate() if exception unwinding reaches a Swift frame. Or the unwinding might continue past the Swift frame with no Swift cleanup run (no `defer` execution, no ARC releases, etc). The behavior might be architecture-dependent because different architectures use different exception machinery on Apple's platforms. > Also, if the method of the call site is marked as "throws," does that mean > the error will propagate out? Nothing you write in Swift will have any effect on C++/ObjC exception unwinding. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
