<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 9:03 AM, David Hart <<a href="mailto:david@wittywings.fr" class="">david@wittywings.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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!)</div><div class=""><br class=""></div><div class="">—Jens</div></body></html>