# Status check: Typed throws **URL:** \ **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:** 20\ **Page:** 2
**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 19, 2023, 10:01pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/21 "2023-09-19T22:01:35Z")
That's fantastic to hear. I only regret that I didn't also include in my original post a status check on that unicorn I've long wanted, or on the whereabouts of my winning lottery ticket. 😆 #### Future directions I think it wise that an initial implementation allow only a single error type to be specified. That addresses important specific use-cases (e.g. embedded) and can be the basis for real-world experience with which to inform future directions. Still, I do want to think a little ahead on future directions, in order to ensure no doors are unwittingly closed. This might be a non-issue, in which case the following is not yet pertinent - I don't know nearly enough about the Swift compiler to even guess. @John_McCall's [post](https://forums.swift.org/t/precise-error-typing-in-swift/52045) does a good job laying out the cons of supporting multiple error types, and why a degree of scepticism is healthy. Still, for the same reason precise error typing is warranted _even though_ it might only be appropriate a minority of the time, I think being able to specify multiple errors types and values has its place too. In a nutshell, I think it's very attractive if thrown errors function much like enums - the caller can see what the possibilities are, the compiler can verify completeness (all enum cases handled or a catch-all provided), etc. But you can already make error enums, today, right?! Yes, but the problem is that composition is essential & frequent yet completely manual today. Most throwing functions call other throwing functions - often _multiple_ with potentially different error types. So you either end up trying to shove every error condition into one giant enum (in the process, losing any indication of which actual error conditions a specific function can encounter) or you waste a lot of time translating between or making wrappers over error types. Either way your code becomes more laborious and error-prone to use & maintain, more verbose, and less flexible. It'd be great if the compiler just did that for you, by implicitly creating those composite enums. So ideally it would be possible to say: - `throws` without an explicit type, equivalent to `throws(any Error)`. - `throws(someType)` means only errors of that type. - `throws(someErrorType, ...)` (or equivalently but IMO less ideally `throws(someErrorType, any Error)`). - `throws(someErrorType, someOtherErrorType)` means errors can be of _either_ type but _not_ any other type. It gets even more powerful when you allow not just error _types_ but _values_, e.g.: - `throws(someErrorEnum.badInput, someOtherErrorEnum.networkError)` - `throws(someErrorEnum.badInput, NetworkError)` (i.e. a mix of types and values) ---
**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 19, 2023, 10:25pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/22 "2023-09-19T22:25:22Z")
> [@wadetregaskis](#): > > But you can already make error enums, today, right?! Yes, but the problem is that composition is essential & frequent yet completely manual today. Most throwing functions call other throwing functions - often _multiple_ with potentially different error types. So you either end up trying to shove every error condition into one giant enum (in the process, losing any indication of which actual error conditions a specific function can encounter) or you waste a lot of time translating between or making wrappers over error types. Either way your code becomes more laborious and error-prone to use & maintain, more verbose, and less flexible. In such cases, you should use untyped `throws`. > [@wadetregaskis](#): > > `throws` without an explicit type, equivalent to `throws(any Error)`. and > [@wadetregaskis](#): > > `throws(someType)` means only errors of that type. are what I'd go for. Also, `throws(Never)` is equivalent to non-throwing. > [@wadetregaskis](#): > > `throws(someErrorType, ...)` (or equivalently but IMO less ideally `throws(someErrorType, any Error)`). From here on, I disagree with the direction you're going. A lot of the motivations and benefits for typed throws taper off once you try to get more specific than "throw this type", because you start creating implicit unions of types and possibly values, you lose the direct relationship with `Result` and throwing, and you end up getting the kind of junk-drawer-of-possibly-thrown-types that plague (e.g.) Java's checked exceptions. Typed throws with a single specified thrown type hits that happy middle. Doug ---
**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 19, 2023, 10:29pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/23 "2023-09-19T22:29:37Z")
> [@Douglas\_Gregor](#): > > Typed throws with a single specified thrown type hits that happy middle. Well, we'll see. 🙂 ---
**Author:** ![bbrk24](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bbrk24/32/27370_2.png) [@bbrk24](https://forums.swift.org/u/bbrk24)\ **Post date:** [September 19, 2023, 10:32pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/24 "2023-09-19T22:32:33Z")
One suggested improvement I've heard for typed throws in languages like Java is ```swift func foo() throws MyError { ... } func bar() throws like foo { try foo() } ``` That way, changing the throw type(s) of `foo` doesn't require changes everywhere. ---
**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\ **Post date:** [September 19, 2023, 10:40pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/25 "2023-09-19T22:40:22Z")
> [@wadetregaskis](#): > > > [@Douglas\_Gregor](#): > > > > Typed throws with a single specified thrown type hits that happy middle. > > Well, we'll see. 🙂 Composition of type union types and typed throws with exactly one type would be more scalable than trying to fit partial support for multiple types in typed throws. (IMO) ```swift func f() throws(Error1 âˆȘ Error2) func g() -> Result ``` > [@bbrk24](#): > > One suggested improvement I've heard for typed throws in languages like Java is > > ```swift > func foo() throws MyError { > ... > } > > func bar() throws like foo { > try foo() > } > > ``` > > That way, changing the throw type(s) of `foo` doesn't require changes everywhere. I don't like `like` part of it. And in general I believe composition of two distinct features is better than some ad-hoc syntax. In particular what you're suggesting could be expressed as ```swift func bar() throws(foo.Throws) ``` where `foo.Throws` is a type of throws of `foo`. Designing it this way reduces the complexity of the Typed Throws feature and gives room for careful thought about how exactly throws' type inference from function reference should work. ---
**Author:** ![bbrk24](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bbrk24/32/27370_2.png) [@bbrk24](https://forums.swift.org/u/bbrk24)\ **Post date:** [September 19, 2023, 11:15pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/26 "2023-09-19T23:15:38Z")
> [@dmt](#): > > I don't like `like` part of it. I didn’t mean to suggest that exact syntax was how it had to be done, just that the concept should exist. I don’t want the capability to get lost in the syntax. ---
**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 20, 2023, 12:57am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/27 "2023-09-20T00:57:09Z")
> [@dmt](#): > > Composition of type union types and typed throws with exactly one type would be more scalable than trying to fit partial support for multiple types in typed throws. (IMO) For sure. It's just that full-blown support for such union types is a much bigger undertaking. That and a bunch of other potential enhancements (e.g. conditional throws, rethrows of more than just immediate parameters, etc) are things I'd love to see too. Again, my emphasis in bringing up support for multiple types is just to ensure it's not inadvertently ruled out in the initial implementation. We won't know if it's worth it - or necessarily how best to implement it, e.g. full union type support vs something more specialised - until we get real-world experience with typed throws to begin with. ---
**Author:** ![ellie20](https://avatars.discourse-cdn.com/v4/letter/e/6f9a4e/32.png) [@ellie20](https://forums.swift.org/u/ellie20)\ **Post date:** [September 20, 2023, 6:13am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/28 "2023-09-20T06:13:51Z")
Something I'd like to add to this discussion is that a possible alternative to enums and union types is protocols, which would discourage people from trying to exhaustively handle each error case, and instead nudge them towards handling the errors using some common functionality that the errors have. This can be made more powerful with "blanket" (protocol-to-protocol) conformances like `extension SomeErrorProtocol: MyErrorProtocol`. For example, there can be a protocol for errors that can display a localized error message or graphical representation for a specific application, while existing types like `CodingError` or `DistributedActorSystemError` can be retroactively conformed to it as necessary. I also wonder if it would be helpful to think of two "kinds" of error handling: 1. General errors, which can potentially come from anywhere in the application. These are normally boxed in existentials and passed around in general-purpose error handling code. Callers should just let them propagate up the stack in most situations, since exhaustively handling each possible case would be impractical. 2. Domain-specific errors, which warrant explicit handling of each possible case close to the call site. These don't necessary have to conform to `Error`, and not conforming to `Error` would prevent them from accidentally "escaping" into general-purpose error handling code if they would not be suitable for it. - Using non-`Error`-conforming enums for domain-specific errors would also prevent a certain class of bugs, where you accidentally handle errors that come from deeper in the call stack than you intended. This occasionally comes up in languages like Python, where exceptions like `KeyError` (from ` __getitem__ `), `StopIteration` (from ` __next__ `), and `ValueError` (when converting strings to other types like int or Decimal) usually signal a special condition to be handled by the caller, but catching them can potentially mask errors deeper in the call stack. Building on one of @wadetregaskis's examples: ```swift func search(query: String) throws SearchError { ... } // Does *not* conform to `Error`, since `.emptyQuery` // should be handled as close to the call site as possible, // and `.other` needs to be unwrapped from the enum before // being propagated to general-purpose error handling code. enum SearchError { case emptyQuery case other(any Error) } do { try search(query: "query") } catch .emptyQuery { // domain-specific error handling... } catch .other(let error) { throw error } ``` ---
**Author:** ![minuscorp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/minuscorp/32/8404_2.png) [@minuscorp](https://forums.swift.org/u/minuscorp)\ **Post date:** [September 20, 2023, 7:21am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/29 "2023-09-20T07:21:55Z")
I'll be glad on helping on whatever is needed for this great proposal! ---
**Author:** ![dhoepfl](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dhoepfl](https://forums.swift.org/u/dhoepfl)\ **Post date:** [September 20, 2023, 9:17am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/30 "2023-09-20T09:17:39Z")
> [@Douglas\_Gregor](#): > > Typed throws with a single specified thrown type hits that happy middle For me, it does not feel like the “happy middle” but like “gave up before it was done”. If there is only one type allowed, I will end up writing boiler plate code to throw an enum for what could have been a list of types in the first place. (Today, it is multiple `as? XXXError`) It’s an exercise for macro coding: Build a macro `@throws(ClassA, ClassB, 
)` for funcs that generates that said enum `#functionName_Error` and adds the `throws #functionName_Error` to the func declaration. ---
**Author:** ![Sajjon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sajjon/32/12044_2.png) [@Sajjon](https://forums.swift.org/u/Sajjon)\ **Post date:** [September 20, 2023, 11:44am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/31 "2023-09-20T11:44:16Z")
(Sorry if this has already been brought up, I did not read every message of this thread) Very excited to hear that you started implementation of Typed Errors 😍 for me this is a Swift improvement almost as exciting as macros! What are your thoughts on (or already working code for) handling "aggregation"/"mapping" of typed errors? I think this will be a super common pattern: ```swift public enum NetworkError: Swift.Error, Sendable, Equatable { case badHTTPResponseCode(Int) } public enum JSONError: Swift.Error, Sendable, Equatable { // naive implementation `DecodingError` made equatable: https://gist.github.com/Sajjon/be1e0204930cef6549e9069094ad577a case decodingError(DecodingError) } public enum MyError: Swift.Error, Sendable, Equatable { case network(NetworkError) case json(JSONError) } public func makeNetworkRequest(path: String) async throws(NetworkError) -> Data { ... } public func decode(data: Data, as: T.Type = T.self) throws(JSONError) -> T { ... } public struct User: Decodable, Sendable, Equatable { ... } ``` And then combine `makeNetworkRequest` and `decode` in a function which throws `MyError`, and then we would have to "manually" aggregate the two thrown error types into our `MyError` type, like so: ```swift /// Uh... cumbersome boilerplaty mapping error types into MyError :/ public func fetchUser(...) async throws(MyError) -> User { do { let data = try await makeNetworkRequest(path: "user/..") return try decode(data: data, as: User.self) } catch let networkError as NetworkError { return .networkError(networkError) } catch let jsonError as JSONError { return .json(jsonError) } } ``` (Here I assume we do not need a "catch-all" `catch {}` since the only two possible error types `NetworkError` and `JSONError` is accounted for.) But what would be amazing, would be some kind of Swift compiler magic, which would allow me to just do: ```swift public func fetchUser(...) async throws(MyError) -> User { let data = try await makeNetworkRequest(path: "user/..") return try decode(data: data, as: User.self) } ``` I'm no compiler engineer, but it feels like this ought to be possible - if and only the MyError enum contained one single case with each of the thrown Error types. Meaning if I would add `case foo(NetworkError)` then such compiler magic would not be possible, since how to know which case the `NetworkError` would go into. And analogously if I were to change `case networkError(NetworkError)` into something silly like `case networkError(NetworkError, url: String)` then that would also make such compiler magic impossible. Now, how badly do I want the two line version? Very very badly :D since just the increased indentation makes the code hard to read, and it is just doing a boilerplaty mapping. And for functions with many many different error types, such mappings really bloats the code base. Surely you have considered this already? is it doable? :) ---
**Author:** ![Sajjon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sajjon/32/12044_2.png) [@Sajjon](https://forums.swift.org/u/Sajjon)\ **Post date:** [September 20, 2023, 11:51am UTC](https://forums.swift.org/t/status-check-typed-throws/66637/32 "2023-09-20T11:51:31Z")
If such compiler magic is not possible, what about some new syntax allowing for shorthand mapping, something like: ```swift public func fetchUser(...) async throws(MyError) -> User { let data = try await makeNetworkRequest(path: "user/..") case .network return try decode(data: data, as: User.self) case .json } ``` or ```swift public func fetchUser(...) async throws(MyError) -> User { let data = as .network try await makeNetworkRequest(path: "user/..") return as .json try decode(data: data, as: User.self) } ``` or: ```swift public func fetchUser(...) async throws(MyError) -> User { let data = try await makeNetworkRequest(path: "user/..") as case .network return try decode(data: data, as: User.self) as case .json } ``` or perhaps: ```swift public func fetchUser(...) async throws(MyError) -> User { let data = try await makeNetworkRequest(path: "user/..") into .network return try decode(data: data, as: User.self) into .json } ``` ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [September 20, 2023, 2:01pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/33 "2023-09-20T14:01:02Z")
It’s great to see progress on typed throws! I have a few design points to consider that are not mentioned in the posts you linked. #### Non-throwing error types Both the proposal draft and the post from @John_McCall post seem to assume all non-throwing functions have error type of `Never`. This would be unfortunate. All functions with uninhabited error types should be considered non-throwing. This implies a tweak to John’s expression for computing a rethrown error type: ```swift func foo(a: () throws(AError) -> Int, b: () throws(BError) -> Int) throws(errorUnion(AError, BError) == Never ? Never : Error) -> Int ``` Becomes ```swift func foo(a: () throws(AError) -> Int, b: () throws(BError) -> Int) throws(errorUnion(AError, BError) == Never || AError is uninhabitable && BError is uninhabitable ? Never : Error) -> Int ``` This expression still leaves something to be desired: `AError` and `BError may have a more specific common supertype than `Error`. Ideally the compiler would be able to figure this out. #### Typed `rethrows` The fundamental semantic of `rethrows` is that a function can only throw when an argument _actually_ throws. In the presence of typed errors, it should be possible to catch and transform errors before rethrowing. This implies it should be possible to write `rethrows TransformedError` regardless of the error types thrown by arguments. In such a function, the body would catch the errors thrown by its arguments and convert them to `TransformedError`. The difference between `throws SomeError` and `rethrows SomeError` would be subtle but important. When writing `rethrows SomeError` it is **only** possible to throw if an argument first throws. The rethrows expression logic above would be modified slightly with the explicitly specified error type replacing `Error` (or the computed common supertype). Thus, `rethrows SomeError` may also be non-throwing depending on the arguments it receives. #### Catch type inference The proposal mentions that type inference for general catch clauses was omitted due to requiring breaking changes. Hopefully this could be included in Swift 6. #### Opaque error types It would be great if error types could be opaque just like return types. I didn’t see any mention of these in the proposal or John’s post and it seems like this feature interaction deserves consideration. ---
**Author:** ![olbo](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/olbo/32/33792_2.png) [@olbo](https://forums.swift.org/u/olbo)\ **Post date:** [September 20, 2023, 2:46pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/34 "2023-09-20T14:46:24Z")
I am not a compiler engineer or language engineer, but would it be possible for the compiler to make the error types implicit? I would like the implicit annotation to extend to unions of errors too, not just `throws` to mean `any Error` - I imagine some developers may want to spell it out in the function signature, but some may prefer the ability to adapt to new error types without updating _all_ signatures in their call stack. For example: ```swift func throwsA() throws { throw A() } func throwsB() throws { throw B() } func throwsAorB() throws { if Bool.random() { throw A() } else { throw B() } } ... do { try throwsA() } catch { // error: A } ... do { try throwsB() } catch { // error: B } ... do { try throwsAorB() } catch let error as A { // error: A } catch let error as B { // error: B } // exhaustive, no need to add `catch` to handle the "any" case ``` ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [September 20, 2023, 2:51pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/35 "2023-09-20T14:51:27Z")
> [@Douglas\_Gregor](#): > > > [@wadetregaskis](#): > > > > Is it worth someone finally doing the real proposal? > > Yes, I think it is. I've become interested in typed throws because it's a good direction for error handling in [Embedded Swift](https://forums.swift.org/t/embedded-swift/67057) Do you have a link handy to any discussions about why precise error handling is useful in Embedded Swift? I vaguely recall seeing one. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [September 20, 2023, 2:54pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/36 "2023-09-20T14:54:49Z")
> [@anandabits](#): > > Both the proposal draft and the post from @John_McCall post seem to assume all non-throwing functions have error type of `Never`. This would be unfortunate. Can you explain why this is important? You have a lot of generic error types that become uninhabited for specific applications? ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [September 20, 2023, 2:56pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/37 "2023-09-20T14:56:44Z")
> [@anandabits](#): > > All functions with uninhabited error types should be considered non-throwing. What's the difference between a non-throwing entity and one that throws `Never`? To me the latter opens up a great generalization where you can easily write generic algorithms including the error types. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [September 20, 2023, 2:57pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/38 "2023-09-20T14:57:36Z")
> [@ksluder](#): > > Do you have a link handy to any discussions about why precise error handling is useful in Embedded Swift? I vaguely recall seeing one. Untyped errors are existentials (`any Error`), which would not be supported in the most restricted embedded environments. If you want to have the ability to throw at all in these environments, it has to be typed. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [September 20, 2023, 2:59pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/39 "2023-09-20T14:59:37Z")
Yikes, okay. In that case, I hope this functionality would never be made available for resilient libraries! I strongly believe such ABI boundaries should _always_ use untyped throws. ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [September 20, 2023, 3:01pm UTC](https://forums.swift.org/t/status-check-typed-throws/66637/40 "2023-09-20T15:01:05Z")
It's useful for `Never` not to be treated specially so that the property of being uninhabited can be composed through other types. You can imagine an adapter function that adds some annotation to an error that passes through it: ```swift struct Decorated { var error: T var decoration: Decoration } func decorateError(in body: () throws(T) -> Void) throws(Decorated) { do { try body() } catch { throw Decorated(error: error, decoration: Decoration(...) } } ``` If the `body` closure doesn't throw, then the error type is `Never`, and `Decorated` is also uninhabited, so `decorateError` can't throw either. [Previous page](https://forums.swift.org/t/status-check-typed-throws/66637.md?page=1) [Next page](https://forums.swift.org/t/status-check-typed-throws/66637.md?page=3)