# \[Pitch\] Returning errors from #expect(throws:) **URL:** \ **Category:** Swift Testing\ **Tags:** swift-testing\ **Created:** [October 23, 2024, 3:50pm UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567 "2024-10-23T15:50:01Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![smontgomery](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/smontgomery/32/965_2.png) [@smontgomery](https://forums.swift.org/u/smontgomery)\ **Post date:** [December 13, 2024, 6:27pm UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567/5 "2024-12-13T18:27:21Z")
Thank you for this proposal @grynspan! I think this will be a great usability enhancement to the `#expect(throws:)` family of macros. The topic of **typed throws** came up again while we were discussing this proposal offline. As @Jnosh mentioned above, that language feature could potentially be very useful so that the type of expected errors could be enforced statically, but as the proposal draft [mentions](https://github.com/swiftlang/swift-testing/blob/76fc54464434802ad293bf07ed186fec7daa6016/Documentation/Proposals/NNNN-return-errors-from-expect-throws.md#alternatives-considered), we don't want to break source compatibility for the common use case of APIs which are plain `throws`. However, we discussed some ideas which may _eventually_ allow adoption of typed throws in a way that only applies to the APIs with explicitly-specified thrown error types. Given that, I suggested the topic be moved from an "Alternative considered" to a "Future direction" in the proposal text. There was no other significant feedback, and this proposal is **accepted**. --- _[View the full topic](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567)._