> On Dec 7, 2015, at 11:39 AM, Jan Neumüller via swift-users
> <swift-users@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
