[swift-evolution] [Pitch] Typed throws

David Waite david at alkaline-solutions.com
Mon Feb 27 23:04:58 CST 2017


> On Feb 27, 2017, at 2:08 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Add more layers, and it can be very mysterious why a call failed. Java at least captures stack traces in this case to aid in technical support in diagnosing the error.
>> 
>> Wrapping exceptions also prevents an aggregate of errors from different subsystems being handled as a category, such as having a catch block handle RecoverableError generically
>> 
>> An interesting solution that has emerged in Ruby to keep library authors from wrapping exceptions is by decorating the existing exception. Exceptions are caught via pattern matching (same as in Swift), so rather than wrap an extension, they extend the error instance with a library-specific module (e.g. swift protocol). So while the error may be a IOError in ruby, you can still catch it via ‘rescue JSONError’
> 
> If I understand this correctly it sounds like introducing a library would create protocols to categorize errors and add retroactive conformances to these protocols for errors thrown by its dependencies?  That is an interesting approach.  But it requires knowing the concrete types of the possible errors all the way down the stack (you can’t add a conformance to an existential).  This seems very problematic to me, especially in a language where creating new error types is as easy as it is in Swift.

I believe it is something that even Objective C can’t do; extend a single instance of a type to support a protocol.

You can still do really interesting things with categories of errors, such as extend existing types to support a protocol, and putting categorization logic on third party errors yourself.

That breaks though if every library does

struct MyError: Error {
   let innerError: Error
}

in order to have a typed throw. 

> Error handling is messy, there’s no doubt about that.  I would like to have as many tools at my disposal as possible.  Error types is one of those tools.

I’m still trying to mentally put together the elevator pitch for typed throws. How do I explain to new/junior developers and developers coming from other languages when to do typed throws, and when not to?

-DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170227/42a35c0a/attachment.html>


More information about the swift-evolution mailing list