> On Aug 20, 2015, at 5:55 PM, Ken Thomases wrote:
>
> On Aug 20, 2015, at 7:29 PM, Carl Hoefs
> wrote:
>>
>> From within a background NSOperationQueue thread, the effects of alarm(3)
>> seem to be ignored. (I use alarm() to interrupt certain system calls like
>> connect() when they stall.)
Just out of curiosity, should Swift allow property methods to throw exceptions?
Seems like a reasonable thing to me, but I don't know what the ramifications
are.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.
On Aug 21, 2015, at 17:27 , Rick Mann wrote:
>
> Just out of curiosity, should Swift allow property methods to throw
> exceptions? Seems like a reasonable thing to me, but I don't know what the
> ramifications are.
It seems to sit naturally in pure Swift syntax, so I wouldn’t be surprised if
I tried to write the extension below, and it compiles just fine. But at runtime
I get
'-[__NSCFBackgroundDownloadTask context]: unrecognized selector sent to
instance 0x7fb6b44f96a0'
I guess this means that __NSCFBackgroundDownloadTask doesn't inherit from
NSURLSessionDownloadTask?
ex
> On Aug 21, 2015, at 18:13 , Quincey Morris
> 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
>
On Aug 21, 2015, at 18:15 , Rick Mann wrote:
>
> 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
> On Aug 21, 2015, at 6:15 PM, Rick Mann wrote:
>
>> On Aug 21, 2015, at 18:13 , Quincey Morris
>> 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) lang
> On Aug 21, 2015, at 20:06 , Greg Parker wrote:
>
>
>> On Aug 21, 2015, at 6:15 PM, Rick Mann wrote:
>>
>>> On Aug 21, 2015, at 18:13 , Quincey Morris
>>> wrote:
>>>
>>> I’d recommend you try to avoid calling the Swift side “exceptions”. It’s
>>> error handling, and although it’s not com
Isn't the net result the same?
Sent from my iPhone
> On Aug 22, 2015, at 12:18 PM, Rick Mann wrote:
>
>
>> On Aug 21, 2015, at 20:06 , Greg Parker wrote:
>>
>>
On Aug 21, 2015, at 6:15 PM, Rick Mann wrote:
On Aug 21, 2015, at 18:13 , Quincey Morris
wrote:
> On Aug 21, 2015, at 8:18 PM, Rick Mann wrote:
>
>> On Aug 21, 2015, at 20:06 , Greg Parker wrote:
>>
>>> On Aug 21, 2015, at 6:15 PM, Rick Mann wrote:
>>>
On Aug 21, 2015, at 18:13 , Quincey Morris
wrote:
I’d recommend you try to avoid calling the Swift side “excepti
> On Aug 21, 2015, at 20:58 , Greg Parker wrote:
>
>> 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.
Sorry, I meant within Swift's error handlin
> On Aug 21, 2015, at 9:00 PM, Rick Mann wrote:
>
>> On Aug 21, 2015, at 20:58 , Greg Parker wrote:
>>
>>> Rick Mann wrote:
>>>
>>> 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 eff
On Aug 21, 2015, at 20:18 , Rick Mann 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 complete
Ah, then there's the biggest difference with "real" exceptions.
Thanks for all the clarification.
> On Aug 21, 2015, at 21:11 , Greg Parker wrote:
>
>
>> On Aug 21, 2015, at 9:00 PM, Rick Mann wrote:
>>
>>> On Aug 21, 2015, at 20:58 , Greg Parker wrote:
>>>
Rick Mann wrote:
14 matches
Mail list logo