[swift-evolution] Proposal: XCTest Support for Swift Error Handling

[Kevin Ballard]

On Sun, Jan 10, 2016, at 11:18 AM, Dmitri Gribenko via swift-evolution wrote:0
> I have significant concerns about doing this.  Consider the following code:
>
> var foo = Foo() do {    XCTAssertEqual(try foo.doSomething(), 42) }
> catch {    XCTAssertEqual(foo.success, false) }
>
> Adding ‘throws’ to the autoclosures will:
>
> (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),

Did you actually test this code? Because this code *does not compile
today*. You cannot pass a throwing expression to an @autoclosure that
takes a non-throwing function. The specific error you get is

error: call can throw, but it is executed in a non-throwing autoclosure

> (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.

Or use it in a throwing @autoclosure.

> 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.
>
> Changing the way control flow works breaks one of the basic language
> features — substitutability:
>
> let bar1 = try bar() foo(bar1)
>
> should be equivalent to:
>
> foo(try bar())

@autoclosure already breaks that. Adding error handling to the
@autoclosure doesn't change anything. In fact, breaking that
substitutability is basically the whole reason for @autoclosure to
exist.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/b7108140/attachment.html>