[swift-users] Parameter Validation

[Jens Alfke]

> 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.

—Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20151207/e5dbbe83/attachment.html>