Re: Swift: should computed properties be able to throw exceptions?

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:

Re: Swift: should computed properties be able to throw exceptions?

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

Re: Swift: should computed properties be able to throw exceptions?

> 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

Re: Swift: should computed properties be able to throw exceptions?

> 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

Re: Swift: should computed properties be able to throw exceptions?

> 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

Re: Swift: should computed properties be able to throw exceptions?

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:

Re: Swift: should computed properties be able to throw exceptions?

> 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

Re: Swift: should computed properties be able to throw exceptions?

> 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

Re: Swift: should computed properties be able to throw exceptions?

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

Re: Swift: should computed properties be able to throw exceptions?

> 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 >

Can't add computed property to NSURLSessionDownloadTask?

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

Re: Swift: should computed properties be able to throw exceptions?

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

Swift: should computed properties be able to throw exceptions?

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.

Re: Using alarm(3) on background NSOperationQueue threads

> 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.)