[swift-evolution] [Pitch] Typed throws

[Dave Abrahams]

on Mon Feb 27 2017, Daniel Leping <daniel-AT-crossroadlabs.xyz> wrote:

> Well, as Dave pointed, you can very rarely recover from an error, which IMO
> is absolutely true.
>
> If your operation fails you don't really care unless you can recover. And
> you know your cases, which you can recover from (in reality one usually
> does it in optimization phase, though).
>
> What else do you need the type of error for at the very end of your call
> stack? In 90% you will tell the user "ah, sorry, something happened. Come
> back later" and log the error (if you haven't forgot it).
>
> In most cases the errors are not for recovering. They neither are to be
> presented to users. They are for developers to read the log/crash
> report/whatever else and analyze it. Most of the errors are for debugging
> purposes.

Disagreed, sorry.  When I said that recovery is rare, I meant that it is
generally done in a very few functions, not that it is rarely possible
at all.  If something goes wrong when editing a document, for example
full or network failure, you simply recover its previous state from the
undo stack.  Errors are *for* recoverable conditions.  If you're not
going to recover you might as well trap and save all the unwinding and
invariant preservation logic.

> I don't want to deal with cumbersome code the purpose of which is to just
> "obey the language rules". Unless I know how to recover I would rethrow it.
> Than catch at the top of the stack and log + show the user a nice "sorry"
> message without getting techy.
>
> On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Feb 27, 2017, at 5:01 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> >
>> >
>> > on Mon Feb 27 2017, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> >
>> >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams <dabrahams at apple.com>
>> wrote:
>> >>>
>> >>>
>> >>> I'm sorry, I don't see any substantive difference, based on what you've
>> >>> written here, between this feature and const.
>> >>
>> >> Let me give it one more shot and then I’ll drop it.  :)
>> >>
>> >> Const is viral because if an API does not declare its arguments const
>> >> it cannot be used by a caller who has a const argument.
>> >
>> > Unless the caller casts away const, thus erasing information that was
>> > previously encoded in the type system.
>>
>> Yes, of course.
>>
>> >
>> >> It is required in order to make an API as generally useful as
>> >> possible.
>> >>
>> >> Typed errors are not viral in this way because no callers are
>> >> prevented from calling an API regardless of whether it declares error
>> >> types or just throws Error like we have today.
>> >
>> > Unless the caller can recover (which is *very* rare) or it catches and
>> > rethrows one of the errors *it* declares, thus erasing information that
>> > was previously encoded in the type system.
>>
>> I view this as being fundamentally different than casting away const.
>> Casting away const says “I know better than the types”.
>>
>> Converting an error to a different type is extremely different.  It much
>> more similar to any other kind of value wrapper a library might create in
>> order to shield its users from being coupled to its implementation details
>> / dependencies.  This is not a way *around* the type system in the sense
>> that casting away const is.  It is a way of *using* the type system
>> (hopefully) to your advantage.
>>
>>
>>
>> >
>> >> Pressure to declare error types in your signature in order to make
>> >> your function as generally useful as possible does not exist.  Each
>> >> function is free to declare error types or not according to the
>> >> contract it wishes to expose.
>> >>
>> >> An argument can be made that community expectations might develop that
>> >> good APIs should declare error types and they could be considered
>> >> viral in this sense because any API that is simply declared `throws`
>> >> is dropping type information.  But I think this overstates the case.
>> >> The community appears to be very sensitive to the problems that can
>> >> arise when error types are too concrete, especially across module
>> >> boundaries.  I think we can learn to use the tool where it works well
>> >> and to avoid it where it causes problems.
>> >>
>> >>>
>> >>> --
>> >>> -Dave
>> >>
>> >
>> > --
>> > -Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

-- 
-Dave