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
