[swift-evolution] Proposal: XCTest Support for Swift Error Handling (Chris Hanson)

Jacob Bandes-Storch jtbandes at gmail.com
Wed Jan 13 02:42:42 CST 2016


To be specific, are you suggesting

func XCTAssertThrowsError<E: ErrorType where E: Equatable>(@autoclosure
expr: () throws -> Void, _ error: E)

?

Jacob Bandes-Storch

On Tue, Jan 12, 2016 at 8:30 AM, Joe Masilotti via swift-evolution <
swift-evolution at swift.org> wrote:

> I agree that being able to assert what type of error is thrown should be
> considered for this proposal. As mentioned in the previous message, a lot
> of Swift core classes have untested code paths due to error throwing and
> catching.
>
> I think that you should be able to assert which error is thrown without
> having to deal with a closure. For example, instead of:
>
> XCTAssertThrowsError(try foo(), { error
>     if error != MyError.Foo {
>         XCTFail(“MyError.Foo was not thrown”)
>     }
> }
>
> I propose:
>
> XCTAssertThrowsError(try foo(), MyError.Foo)
>
> This removes more boiler plate code for the developer to write, the
> initial goal of this proposal. Also, the original proposed approach
> requires the developer to remember to fail if the error wasn’t the correct
> type. Forgetting to explicitly fail might not actually test anything.
>
> Joe Masilotti
> Masilotti.com
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160113/97e71491/attachment.html>


More information about the swift-evolution mailing list