[swift-users] Parameter Validation
jens at mooseyard.com
Mon Dec 7 19:37:35 CST 2015
> On Dec 7, 2015, at 5:24 PM, David Hart <david at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-users