Swift Testing: Return Errors From #expect(throws:)
Also new in Swift 6.1, ST-0006:
We offer three variants of
#expect(throws:):
- One that takes an error type, and matches any error of the same type;
- One that takes an error instance (conforming to
Equatable) and matches any error that compares equal to it; and- One that takes a trailing closure and allows test authors to write arbitrary validation logic.
The third overload has proven to be somewhat problematic. First, it yields the error to its closure as an instance of
any Error, which typically forces the developer to cast it before doing any useful comparisons. Second, the test author must returntrueto indicate the error matched andfalseto indicate it didn’t, which can be both logically confusing and difficult to express concisely[…]
Note that, with Swift 6.0, only the third variant actually lets you access the thrown error. So that’s what I always used, but I found it awkward. I’d been using a helper method to make it a little better:
func expect<T, E>(sourceLocation: SourceLocation = #_sourceLocation,
_ performing: () throws -> T,
throws errorChecker: (E) -> Void) {
// @SwiftIssue: Must write this separately or it won't type-check.
func errorMatcher(_ e: any Error) throws -> Bool {
let error = try #require(e as? E, sourceLocation: sourceLocation)
errorChecker(error)
return true
}
#expect(sourceLocation: sourceLocation,
performing: performing,
throws: errorMatcher)
}
This would do the cast, but I think it was still not great:
expect {
try // something
} throws: { (error: MJTError) in
// check `error`
}
With Swift 6.1, the first two variants return the matched error, so I can just write:
let error = try #require(throws: MJTError.self) {
try // something
}
// check `error`
Much better! Note that I’ve switched from #expect to #require because it doesn’t really work to do:
if let error = #expect(throws: MJTError.self) // ...
The if doesn’t interact well with the trailing closure syntax, so I think I would have to write it like:
let error = #expect(throws: MJTError.self) {
try // something
}
if let error {
// check `error`
}
if I really wanted to continue after the error didn’t match.
Note that if you don’t care what the error is but do want to look at it, you can pass (any Error).self as the error type.
I was also wondering, now that we have typed throws, why doesn’t it check at compile time that the test code throws the right type of error? The answer:
If we adopted typed throws in the signatures of these macros, it would force adoption of typed throws in the code under test even when it may not be appropriate. For example, if we adopted typed throws, the following code would not compile[…]
Previously:
- Xcode 16.3
- Swift Testing: Test Scoping Traits
- Swift 6.1
- Issues Adopting Swift Testing
- Swift Proposal: Typed Throws
