<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div><br>On 08 Dec 2015, at 01:43, Jens Alfke via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 11:39 AM, Jan Neumüller via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I fail to see any overhead here. Its the absolute minimum to get checked values. Anything less is not checking.</div></div></blockquote></div><br class=""><div class="">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.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">—Jens</div><div class=""><br class=""></div><div class="">* NSError itself isn’t that old, but before that the APIs still returned nil or false for runtime errors.</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43hXwizS3O2z60WweqomIrdgZk-2BoSk5AzMgN3t5TzBUTmL9GpD90-2FZDI0TYakEdmYpO8lJLeGlRycaSEjDyPUB0SJqmj7eRuuDbWf21LqO98Vpvr6kwqeIf9Pqf5fGEVj74Ka2fRcXYdcnz1yA2itG4wzcHZrwXMxU8XG-2B58-2BYZPU5GdC0JdQJY0wT5ozp-2F2Ox68v2Q806tunm3zNbSiU0Ro-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-users mailing list</span><br><span><a href="mailto:swift-users@swift.org">swift-users@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-users">https://lists.swift.org/mailman/listinfo/swift-users</a></span><br></div></blockquote></body></html>