Re: Swift: should computed properties be able to throw exceptions?
Re: Swift: should computed properties be able to throw exceptions?
- Subject: Re: Swift: should computed properties be able to throw exceptions?
- From: Greg Parker <email@hidden>
- Date: Fri, 21 Aug 2015 20:58:11 -0700
> On Aug 21, 2015, at 8:18 PM, Rick Mann <email@hidden> wrote:
>
>> On Aug 21, 2015, at 20:06 , Greg Parker <email@hidden> wrote:
>>
>>> On Aug 21, 2015, at 6:15 PM, Rick Mann <email@hidden> wrote:
>>>
>>>> On Aug 21, 2015, at 18:13 , Quincey Morris <email@hidden> 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 email@hidden Runtime Wrangler
_______________________________________________
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