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

Dmitri Gribenko gribozavr at gmail.com
Sun Jan 10 13:18:14 CST 2016

On Sat, Jan 9, 2016 at 6:58 PM, Chris Hanson via swift-evolution <
swift-evolution at swift.org> wrote:

> Allowing Test Assertions to Throw Errors
> We can also allow the @autoclosure 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:
> func testVendingMultipleItemsWithSufficientFunds() {
>     vendingMachine.deposit(10)
>     XCTAssertEqual(try vendingMachine.vend(row: 1, column: 1), "Candy Bar")
>     XCTAssertEqual(try vendingMachine.vend(row: 1, column: 2), "Chips")}
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),

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

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

should be equivalent to:

foo(try bar())


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/0ee4c193/attachment.html>

More information about the swift-evolution mailing list