> On Feb 27, 2017, at 11:04 PM, David Waite <da...@alkaline-solutions.com>
> wrote:
>
>
>> On Feb 27, 2017, at 2:08 PM, Matthew Johnson <matt...@anandabits.com
>> <mailto:matt...@anandabits.com>> wrote:
>>
>>>
>>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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.
Ok, I missed that it was a single instance, not all values with a given error
type.
>
> 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.
Did you see my suggestion for adding underlying and originating error
properties to the `Error` protocol? That would solve the problem of every
library doing this themselves and make it much easier to identify what happened
at the bottom of the stack when you really need to know that (without manually
extracting wrapped errors all the way down).
>
>> 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?
IMO this is not that much different than any other aspect of API design. This
isn’t so much an elevator pitch as an education that error handling is messy
and complicated and requires just as much thought in designing an API as the
happy path does. Nobody enjoys thinking about errors. This is an opportunity
to help teach junior developers to think more carefully about them.
Help junior developers learn to think about users of an API and think about
dependencies and coupling. When a user is calling this API how might they want
to handle errors that might be thrown? How can the error type help facilitate
that? On the other hand, when is an API exposing too much concrete type
information to callers that creates unnecessary coupling? When that is the
case, how can we best remove enough type information to avoid that coupling
(i.e. wrapping, exposing an existential, etc)?
>
> -DW
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
