[swift-users] Parameter Validation

Jan Neumüller nasan at slayers.de
Mon Dec 7 12:56:19 CST 2015


But what overhead? As you know Swift has *NO* exceptions. It’s just syntax sugar for normale error values.

Jan


> On 07.12.2015, at 18:18, Jens Alfke via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On Dec 7, 2015, at 9:03 AM, David Hart <david at wittywings.fr <mailto:david at wittywings.fr>> wrote:
>> 
>> But then you can't unit-test that the function fails on those parameters. To look at a counter-argument, both C# and Java would throw exceptions for parameter validation.
> 
> I agree, that’s a drawback. But the alternative of ‘throwing’ an exception adds so much overhead that it’s IMHO a non-starter. Except in the case where the method can already return/throw errors, but that’s not always going to be the case. Operator overloads are a particular problem for errors — consider range-checking the index to a subscript operator: you have no choice but an assertion, since that method is incapable of returning/throwing errors.
> 
> As I said yesterday, I think the best solution is to make the unit testing framework somehow capable of magically recovering from assertion failure. (Which it might be already, at least on Apple platforms — I haven’t explicitly tested what XCTest does, but I don’t remember my test suites ever completely bombing out due to an assertion failure. IIRC they just continue to the next test. But it’s possible I’m forgetting!)
> 
> —Jens
> 
> _______________________________________________
> 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/20151207/8ee64923/attachment.html>


More information about the swift-users mailing list