<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="">I think I am in full agreement with Dmitri on this: The XCTAssertThrowsError should be the only one that interacts with errors and that others should not try to hijack the try.<div class=""><div class=""><br class=""></div><div class="">But super-big +1 on the XCTAssertThrowsError being in place to verify error cases; swift-corelibs-foundation is missing a lot of testing of error cases and it would be nice to have an effort to start verifying those (and their structures)</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 10, 2016, at 11:18 AM, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 9, 2016 at 6:58 PM, Chris Hanson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)" class="">Allowing Test Assertions to Throw Errors</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">We can also allow the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">@autoclosure</code> expression that is passed into an assertion to throw an error, and treat that error as an unexpected failure (since the code is being invoked in an assertion that isn't directly related to error handling). For example:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-radius:3px;font-family:Consolas,Monaco,'Andale Mono','Ubuntu Mono',monospace;direction:ltr;word-wrap:normal;background-color:rgb(245,242,240)" class=""><code style="margin:0px;padding:0px;border:none;border-radius:3px;font-family:Consolas,Monaco,'Andale Mono','Ubuntu Mono',monospace;direction:ltr;word-spacing:normal;word-wrap:normal;line-height:1.5;background-color:transparent" class=""><span style="color:rgb(0,119,170)" class="">func</span> <span style="color:rgb(221,74,104)" class="">testVendingMultipleItemsWithSufficientFunds</span><span style="color:rgb(153,153,153)" class="">(</span><span style="color:rgb(153,153,153)" class="">)</span> <span style="color:rgb(153,153,153)" class="">{</span>
vendingMachine<span style="color:rgb(153,153,153)" class="">.</span><span style="color:rgb(221,74,104)" class="">deposit</span><span style="color:rgb(153,153,153)" class="">(</span><span style="color:rgb(153,0,85)" class="">10</span><span style="color:rgb(153,153,153)" class="">)</span>
<span style="color:rgb(221,74,104)" class="">XCTAssertEqual</span><span style="color:rgb(153,153,153)" class="">(</span><span style="color:rgb(0,119,170)" class="">try</span> vendingMachine<span style="color:rgb(153,153,153)" class="">.</span><span style="color:rgb(221,74,104)" class="">vend</span><span style="color:rgb(153,153,153)" class="">(</span>row<span style="color:rgb(153,153,153)" class="">:</span> <span style="color:rgb(153,0,85)" class="">1</span><span style="color:rgb(153,153,153)" class="">,</span> column<span style="color:rgb(153,153,153)" class="">:</span> <span style="color:rgb(153,0,85)" class="">1</span><span style="color:rgb(153,153,153)" class="">)</span><span style="color:rgb(153,153,153)" class="">,</span> <span style="color:rgb(102,153,0)" class="">"Candy Bar"</span><span style="color:rgb(153,153,153)" class="">)</span>
<span style="color:rgb(221,74,104)" class="">XCTAssertEqual</span><span style="color:rgb(153,153,153)" class="">(</span><span style="color:rgb(0,119,170)" class="">try</span> vendingMachine<span style="color:rgb(153,153,153)" class="">.</span><span style="color:rgb(221,74,104)" class="">vend</span><span style="color:rgb(153,153,153)" class="">(</span>row<span style="color:rgb(153,153,153)" class="">:</span> <span style="color:rgb(153,0,85)" class="">1</span><span style="color:rgb(153,153,153)" class="">,</span> column<span style="color:rgb(153,153,153)" class="">:</span> <span style="color:rgb(153,0,85)" class="">2</span><span style="color:rgb(153,153,153)" class="">)</span><span style="color:rgb(153,153,153)" class="">,</span> <span style="color:rgb(102,153,0)" class="">"Chips"</span><span style="color:rgb(153,153,153)" class="">)</span>
<span style="color:rgb(153,153,153)" class="">}</span></code></pre></div></div></div></div></div></div></div></div></div></blockquote></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I have significant concerns about doing this. Consider the following code:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">var foo = Foo()</div><div class="gmail_extra">do {</div><div class="gmail_extra"> XCTAssertEqual(try foo.doSomething(), 42)</div><div class="gmail_extra">} catch {</div><div class="gmail_extra"> XCTAssertEqual(foo.success, false)</div><div class="gmail_extra">}</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Adding ‘throws’ to the autoclosures will:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">(1) change meaning of existing tests (the example above used to proceed to the catch block in case of errors, and will start failing with this change),</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">(2) hijacks ‘try’ and defeats its purpose — being able to understand the control flow. Developers know that if they see a ‘try’, it should match with either a do-catch, or be used in a throwing function. Adding this API makes the code misleading.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Note that although (2) applies to the XCTAssertThrowsError() API, because the name of that API makes it clear it is doing something special with error handling, I’m not concerned about it. But adding error handling to regular assertion functions has the potential to create misleading code.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Changing the way control flow works breaks one of the basic language features — substitutability:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">let bar1 = try bar()</div><div class="gmail_extra">foo(bar1)</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">should be equivalent to:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">foo(try bar())</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Dmitri</div><div class=""><br class=""></div>-- <br class=""><div class="">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank" class="">gribozavr@gmail.com</a>>*/</div>
</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=0mkChau6XnFV-2FCNUik62L9ZaldD0W0ziOwj-2F3jLx36-2FiBqNbEu3lWW2rx8NLpokjwbnnolsSmGAAC2PzqlNIZJr0VTr0ixqeiXGGnrLnnxnITMA-2FMCXG7MAXMcXQgn7h5xMaIgKCnFNztVBIK8HuarG8Yb03MTjI1J5s28a4Ogvl37cX4C-2BUYfaQC0Ia4qwj1QnyulI9p5-2FPaMPIkA1fVqUGoFSN6R5r4PhMSXlRKNU-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;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>