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.
On Tue, Jan 12, 2016 at 8:30 AM, Joe Masilotti via swift-evolution < swift-evolution@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.