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 gpar...@apple.com wrote:
On Aug 21, 2015, at 9:00 PM, Rick Mann rm...@latencyzero.com wrote:
On Aug 21, 2015, at 20:58 , Greg Parker gpar...@apple.com 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 effect on C++/ObjC exception
unwinding.
Sorry, I meant within Swift's error handling, if the call site does nothing
other than be a function marked with throws, that's legal right?
func
one() throws
{
two()
}
func
two() throws
{
throw something
}
It is not legal. All call sites to methods that may throw must use `try`. The
call site must explicitly acknowledge the possibility of an error.
test.swift:4:4: error: call can throw but is not marked with 'try'
two()
^
--
Greg Parker gpar...@apple.com Runtime Wrangler
--
Rick Mann
rm...@latencyzero.com
___
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
Re: Swift: should computed properties be able to throw exceptions?
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. -- 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
Re: Swift: should computed properties be able to throw exceptions?
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? Also, if the method of the call site is marked as throws, does that mean the error will propagate out? Pity it's not a real exception mechanism. -- Rick Mann rm...@latencyzero.com ___ 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
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 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? Also, if the method of the call site is marked as throws, does that mean the error will propagate out? Pity it's not a real exception mechanism. -- Rick Mann rm...@latencyzero.com ___ 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/dangerwillrobinsondanger%40gmail.com This email sent to dangerwillrobinsondan...@gmail.com ___ 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
Re: Swift: should computed properties be able to throw exceptions?
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
Re: Swift: should computed properties be able to throw exceptions?
On Aug 21, 2015, at 20:58 , Greg Parker gpar...@apple.com 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 handling, if the call site does nothing
other than be a function marked with throws, that's legal right?
func
one() throws
{
two()
}
func
two() throws
{
throw something
}
--
Rick Mann
rm...@latencyzero.com
___
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
Re: Swift: should computed properties be able to throw exceptions?
On Aug 21, 2015, at 9:00 PM, Rick Mann rm...@latencyzero.com wrote:
On Aug 21, 2015, at 20:58 , Greg Parker gpar...@apple.com 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 effect on C++/ObjC exception
unwinding.
Sorry, I meant within Swift's error handling, if the call site does nothing
other than be a function marked with throws, that's legal right?
func
one() throws
{
two()
}
func
two() throws
{
throw something
}
It is not legal. All call sites to methods that may throw must use `try`. The
call site must explicitly acknowledge the possibility of an error.
test.swift:4:4: error: call can throw but is not marked with 'try'
two()
^
--
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
Re: Swift: should computed properties be able to throw exceptions?
On Aug 21, 2015, at 20:18 , Rick Mann rm...@latencyzero.com 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 rm...@latencyzero.com 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 (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
Re: Swift: should computed properties be able to throw exceptions?
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). In any case good to know I'm not off my rocker in thinking properties could throw except--errors. -- Rick Mann rm...@latencyzero.com ___ 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
Re: Swift: should computed properties be able to throw exceptions?
On Aug 21, 2015, at 18:15 , Rick Mann rm...@latencyzero.com 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 opposed to, say, returning a boolean true/false to indicate an error). In fact they are the latter. That is, there is conceptually a hidden ErrorType output parameter, and a special return value that indicates that an error occurred and the output parameter has been given a value. It’s compatible with (and transparently bridged to/from) the Obj-C error pattern that has a NSError** parameter, and a return type of true/false or nil/non-nil. (I don’t recall for certain, but I believe the Swift side is not compatible with Obj-C code that returns some other kind of value indicator, such as NSNotFound, but if there are any such in Cocoa — that also have a NSError** parameter, I mean — they are extremely rare.) Again, at the call site, conceptually, there is a hidden ‘if’ test on the called method result, exactly as if you were testing for errors in Obj-C. It’s the error handling pattern you already know, just with the boring details hidden from view. However, if you look at this completely in Swift, it’s very much like an exception. The main differences are in the implementation — a “real” exception is generally a direct transfer of control from the point of the throw to the point of the catch, along with system library code to keep track of possible catch points and to invoke destructors/local recovery before the transfer. In Swift, conceptually, there’s just an ordinary return from method to method up the stack until the error is handled. Obviously, with this convention you could translate a (hypothetical) Swift getter or setter into an Obj-C method, but that method wouldn’t be an Obj-C getter or setter, because of the extra parameter. This impedance mismatch is, I believe, what’s standing in the way of letting Swift accessors throw errors. ___ 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
Re: Swift: should computed properties be able to throw exceptions?
On Aug 21, 2015, at 17:27 , Rick Mann rm...@latencyzero.com 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 it shows up as a language feature before long. However, the drawback is that it’s not compatible with Obj-C-style methods. That’s because Obj-C properties have no mechanism for handling the transfer of control implied by Swift throw/try. 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. ___ 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
