[swift-users] Parameter Validation

[David Hart]

You enable assertions for release builds then? 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.

> On 08 Dec 2015, at 01:43, Jens Alfke via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On Dec 7, 2015, at 11:39 AM, Jan Neumüller via swift-users <swift-users at swift.org> wrote:
>> 
>> I fail to see any overhead here. Its the absolute minimum to get checked values. Anything less is not checking.
> 
> There’s no overhead if the function already ‘throws’ / returns errors. But not all functions do that (and some functions _cannot_ do that, like operators.) If a function has to be upgraded to return an error, that _is_ extra overhead, mostly on the caller’s side. (And, as previously noted, this may complicate the programmer’s life too, because now they may have to either propagate ‘throws’ to the caller or add a ‘catch’ handler.)
> 
> Anyway, the programming conventions have been clear for a very long time: assertions should be used for programmer errors (like invalid parameters) while returned errors should be used for legitimate runtime error situations (like file-not-found). This predates Swift and even predates Mac OS X*; I think it goes back to OpenStep in the mid-‘90s.
> 
> —Jens
> 
> * NSError itself isn’t that old, but before that the APIs still returned nil or false for runtime errors.
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20151208/de2ed184/attachment.html>