# Status check: Typed throws

**URL:** <https://forums.swift.org/t/status-check-typed-throws/66637>\
**Category:** Discussion\
**Tags:** exceptions, typed-throws\
**Created:** [August 7, 2023, 8:55pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637 "2023-08-07T20:55:45Z")\
**Posts on this page:** 7\
**Page:** 8

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [September 23, 2023, 11:20pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/143 "2023-09-23T23:20:06Z")

</div>

I was concerned that would be the case, but was hopeful nonetheless. Doesn’t hurt to ask the question. Thank you for the erudite responses.

---

<div class="post-metadata">

**Author:** ![Zollerboy1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zollerboy1/32/12997_2.png) [@Zollerboy1](https://forums.swift.org/u/Zollerboy1)\
**Post date:** [September 24, 2023, 12:23am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/144 "2023-09-24T00:23:42Z")

</div>

> [@toph42](#):
>
> In a world where Swift has typed throws, what specifically are the pitfalls an uninitiated developer might fall prey to in their API design?

Many people are saying that API stability would be a problem, I think.

Let's say I have the following function in my library:

```swift
func getContents(ofURL urlString: String) async throws (NetworkError) -> Data {
    let url = URL(fromString: urlString)!
    return try await getData(url)
}

```

But now I decide that I want to throw a `URLParsingError` when the URL parsing fails. Since I already committed to the fact that `getContents(ofURL:)` only throws a `NetworkError`, I cannot just throw another error, so I have to change my function signature, which could be a source break for many clients of my library. Therefore I can only make this change in a new major version of my library. This dilemma could have been avoided, had I just used an untyped throws instead.

* * *

Although I can understand this argument against typed throws, I personally don't find it that compelling. Sure, some people can and will misuse typed throws, but most people won't, since we will leave untyped throws as the default. I can also see that it is actually nice, that I could actually notify the users of my library that there is a new error that might be thrown from a function which they might care about. With untyped errors, users often write catch-all clauses that aren't that helpful, because they either just crash or just print the unknown error.  
Also, I think it's a bit odd that the thrown error is singled out as something that should not break sources when changed, while everything else about a function (argument types, return type, etc.) still does. What is the big difference?

---

<div class="post-metadata">

**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\
**Post date:** [September 24, 2023, 12:45am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/145 "2023-09-24T00:45:38Z")

</div>

> [@Zollerboy1](#):
>
> Let's say I have the following function in my library:
> 
> ```swift
> func getContents(ofURL urlString: String) async throws (NetworkError) -> Data {
> let url = URL(fromString: urlString)!
> return try await getData(url)
> }
> 
> ```
> 
> But now I decide that I want to throw a `URLParsingError` when the URL parsing fails. Since I already committed to the fact that `getContents(ofURL:)` only throws a `NetworkError`, I cannot just throw another error, so I have to change my function signature, which could be a source break for many clients of my library. Therefore I can only make this change in a new major version of my library. This dilemma could have been avoided, had I just used an untyped throws instead.

Yeah, but it's already true - maybe later you decide it should return a `String` instead of `Data`, or a file handle, or whatever else. Or you decide it should really take an actual `URL` rather than a `String`.

This does raise a question, however, about overloading. I think we've all been assuming you can't overload a method based on its throw type(s). Although my instinct is to concur with that presumption, it's worth exploring.

If throws overloading isn't permitted, then that does become a meaningful distinction, as function parameters and return types _can_ be overloaded in Swift (although the latter is apparently widely regarded as a mistake, due to its burden on type inference). Overloading is not a panacea but sometimes is a useful escape hatch for what would otherwise have to be an ABI-breaking change.

> [@Zollerboy1](#):
>
> Sure, some people can and will misuse typed throws, but most people won't, since we will leave untyped throws as the default.

Yeah, that's an aspect of the counter-position that I'm still puzzled by. Is it that opponents are concerned as some kind of matter of principle - that they think _nobody_ should have the functionality even if it doesn't effect them - or is it a concern that in practice there'll be some "viral" aspect which will coerce them into using typed throws when they don't want to? If the latter, I'd like to see that demonstrated a bit more clearly, as I don't see any reason why untyped catch clauses - i.e. `} catch {`, as are very common today - wouldn't continue to be universally acceptable (to the compiler) and effectively defend borders.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [September 25, 2023, 4:25am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/146 "2023-09-25T04:25:47Z")

</div>

Hey all,

A quick update: I've kicked off a [new pitch thread](https://forums.swift.org/t/pitch-n-1-typed-throws/67496) with a complete proposal.

Doug

---

<div class="post-metadata">

**Author:** ![rdemarest](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rdemarest/32/3057_2.png) [@rdemarest](https://forums.swift.org/u/rdemarest)\
**Post date:** [October 11, 2023, 2:02am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/147 "2023-10-11T02:02:42Z")

</div>

Should we allow a comma list of error types rather than limit it to one type of error?

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [October 11, 2023, 2:18am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/148 "2023-10-11T02:18:32Z")

</div>

I’m going to close this thread now, further discussion should happen on the [new pitch thread](https://forums.swift.org/t/pitch-n-1-typed-throws/67496).

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [October 11, 2023, 2:18am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/149 "2023-10-11T02:18:44Z")

</div>



[Previous page](https://forums.swift.org/t/status-check-typed-throws/66637.md?page=7)