[swift-evolution] [Pitch] Typed throws

[Karl Wagner]

> On 18 Feb 2017, at 16:27, Karl Wagner <karl.swift at springsup.com> wrote:
> 
> - I wonder if we could try something more ambitious. Since the list of thrown errors is resilience-breaking for the function, it is only beneficial for versioned and @inlineable functions. They should not be able to add new errors (they can remove them though, since errors are intended to be switched over). I wonder if we couldn’t introduce a small pattern grammar for our structured comments (isolated from the rest of the language) - it would be optional, but if you do list your errors, the compiler would validate that you do it exhaustively. Some patterns I would like are:
> 
> // - throws: - MyError.{errorOne, errorThree, errorFive}: Something bad      || considered exhaustive
> @inlineable public func canFail() throws {}
> 
> // - throws: - OpeningError: Computer says nooooo...     || considered exhaustive if OpeningError is versioned or @fixed
> //           - *                                         || other errors, requires “catch-all” by external callers
> @inlineable public func canFail2() throws {}
> 
> If we want to get really clever, we can have the compiler automatically generate those error-lists for internal functions, so you would automatically get exhaustive error-handling within your own module.
> 
> - Karl

Just to rephrase this a little bit.

- The list of thrown errors would not be part of the function’s signature. Instead, there is an ABI invariant that it throws an Error, and that it remains "switch-compatible". That’s a loose definition, but it covers things like throwing non-public Errors and later making them public while retaining ABI compatibility.
- It’s up to the library developer to maintain that invariant. They can remove errors, refine errors (e.g. “MyError” -> “MyError.{errorOne, errorThree}”), hide or reveal previously-hidden errors.
- If the errors are listed exhaustively, the compiler will generate an implicit catch-all to trap in case the library violates this invariant. This means they can become more specific while retaining ABI compatibility.

- We would put this information in the structured comments, because it can get long and complex and is always optional
- The compiler would ensure that their documentation is accurate, as it does any other part of the language.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170218/7e183a92/attachment.html>