Click on the magnifying glass in the top right corner and write "typed throws" without the quotation marks. You will find many discussions dating back several years:
[Discussion] Analysis of the design of typed throws
Feb '17 - # Analysis of the design of typed throws ## Problem There is a problem with how the proposal specifies rethrows for functions that take more than one throwing function. The proposal...
Feb '17 - Now this is on-topic, I guess. Last time we stopped at John McCall’s syntax: extension MyError: Error { ... } func foo() throws(MyError) - > MyResult It’s conservative and prevents visual ambiguity with extra parentheses. If we (somewhat) agree on this, then submitting a proposal will be trivial.
Aug '17 - Splitting this off into its own thread: One related topic that isn’t discussed is type errors. Many third party libraries use a Result type with typed errors. Moving to an async / await model without also introducing typed errors into Swift would require giving up something that is highly valued by...
Feb '17 - I’ve created a proposal draft, copy-pasting some parts from David Owens’ proposal. Here it is < Draft of "Typed throws" proposal · GitHub Draft of "Typed throws" proposal · GitHub > . I had to make one addition, which hasn’t been discussed yet. Look at ...
Is it possible to specify error type thrown in a protocol method
Jul '17 - Hi Swifters, I am wondering if it is possible to specify error types thrown in a protocol method. By allowing us to do it and letting the compiler check all the implementations of the protocol to make sure only they would only throw the specified error types, we only need to catch our error types...
Dec '15 - IMHO be careful what you wish for. If the compiler enforces this then we're just repeating the mistakes of Java's checked exceptions. All roads would eventually lead to "throws ErrorType", defeating the supposed purpose. russ
Dec '15 - ...ke a billion times already, but I'd like to be official and make a proper proposal for that. So having said that, I hereby propose adding support for typed throws annotations. If a function can throw, it is often known what type of error it may throw. Consider this piece of code: enum NetworkError: Err...
Proposal: Allow Type Annotations on Throws
Dec '15 - This a significantly updated proposal for typed annotations on the throws construct. The previous was closed due to not be complete; I believe I’ve addressed all of those concerns. https://github...
Aug '16 - Hi all, Currently, a function that throws is assumed to throw anything. There was a proposal draft last December to restrict that. The general idea was that you'd write, for instance: enum Foo: ErrorProtocol { case bar case baz } func frob() throws Foo { throw Foo.bar // throw .bar? } If you `cat...
Proposal: Allow Type Annotations on Throws
Jan '16 - ...g/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html [swift-evolution] Proposal: Allow Type Annotations on Throws > on "typedthrows". First of all, I just love the improvement from the caller point of view. The following: func updateData() throws DataUpdateError - > Data do...
[PITCH] Add Ability To Specify Error Type On Throws
Aug '16 - Hello, Consider the scenario of the vending machine example in the Swift Book: We have a function that throws errors from a single given ErrorType 1. func vend(itemNamed name: String) throws { 2. guard let item = inventory[name] else { 3. throw VendingMachineError.InvalidSelection 4. } 5. 6. guar...
Add ability to specify the error type on throws
Aug '16 - Hello, Consider the scenario of the vending machine example in the Swift Book: We have a function that throws errors from a single given ErrorType 1. func vend(itemNamed name: String) throws { 2. guard let item = inventory[name] else { 3. throw VendingMachineError.InvalidSelection 4. } 5. 6. guar...