# \[Pitch\] Returning errors from #expect(throws:)

**URL:** <https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567>\
**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:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\
**Post date:** [October 23, 2024, 3:50pm UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567/1 "2024-10-23T15:50:01Z")

</div>

Swift Testing includes overloads of `#expect()` and `#require()` that can be used to assert that some code throws an error. They are useful when validating that your code's failure cases are correctly detected and handled. However, for more complex validation cases, they aren't particularly ergonomic. This proposal seeks to resolve that issue by having these overloads return thrown errors for further inspection.

Read the full pitch [here](https://github.com/swiftlang/swift-testing/pull/780).

---

<div class="post-metadata">

**Author:** ![Jnosh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jnosh/32/37375_2.png) [@Jnosh](https://forums.swift.org/u/Jnosh)\
**Post date:** [October 24, 2024, 10:12am UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567/2 "2024-10-24T10:12:02Z")

</div>

Looking forward to this for the reasons outlined in the proposal. Being able to do this a little more ergonomically will be nice!

Out of curiosity, would it still be possible in the future to also add variants that use typed throws to deduce the error type or would that end up being ambiguous?

---

<div class="post-metadata">

**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\
**Post date:** [October 24, 2024, 1:20pm UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567/3 "2024-10-24T13:20:51Z")

</div>

If you wanted to rely on type inference to avoid the `throws:` argument, you'd end up with something like:

```swift
#expect {
  try foo()
}

```

Which would be ambiguous to the reader even if the compiler understood. (And no, we don't want to rename it `#expectThrows {}` 😬.)

Embedded Swift on the other hand will require overloads that use typed throws, but that's beyond the scope of this pitch as we don't support Embedded Swift yet.

The existing API (including the proposed changes) should be sufficient here, but if there's a use case you know of that would require typed throws, let me know!

---

<div class="post-metadata">

**Author:** ![Jnosh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jnosh/32/37375_2.png) [@Jnosh](https://forums.swift.org/u/Jnosh)\
**Post date:** [October 24, 2024, 2:02pm UTC](https://forums.swift.org/t/pitch-returning-errors-from-expect-throws/75567/4 "2024-10-24T14:02:41Z")

</div>

Indeed, I was only wondering if inferring the type for typed throws cases would work or end up being confusing as you mention. So your explanation answered my question. 🙂

---

<div class="post-metadata">

**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")

</div>

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