# 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:** 1\ **Showing post:** 21
**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) --- _[View the full topic](https://forums.swift.org/t/status-check-typed-throws/66637)._