> On Dec 7, 2015, at 5:24 PM, David Hart <da...@hartbit.com> wrote:
>
> You enable assertions for release builds then?
It depends on the target. In a lot of app-level code it doesn’t make much
difference to leave them in, while in lower-level performance-sensitive code
it’s a big slowdown. (Back when I worked at Apple, a lot of system apps shipped
with assertions enabled.)
But that’s irrelevant. If you had to add a ‘throws’ declaration to a function
to add error handling to it in debug builds, it’s still going to have the
overhead of ‘throws’ in a release build even if the error check is suppressed
somehow.
> Remember, I'm talking specifically about library code: the same way that
> calling NSArray's objectAtIndex throws an exception (if my memory serves
> well) for out of bounds indices. At least, NSAssert in Objective-C throws
> exceptions and is catchable.
(a) Obj-C exceptions (which are bridged to C++ exceptions) don’t incur any
overhead, unlike Swift ‘throws’ functions. They have no direct equivalent in
Swift.
(b) You’re not _supposed_ to catch NSAssertion failures, or at least not let
your app continue afterwards. Cocoa has always had a weird ambivalence about
exceptions: they’re part of the Obj-C language, but their use is discouraged,
and the docs have become increasingly direct about telling you not to
catch-and-continue.
—Jens
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
