> 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
