[swift-evolution] typed throws

[Dave Abrahams]

on Thu Aug 17 2017, John McCall <swift-evolution at swift.org> wrote:

>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> Splitting this off into its own thread:
>> 
>>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 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
>>> many Swift developers.  Maybe Swift 5 is the right time to tackle
>>> typed errors as well.  I would be happy to help with design and
>>> drafting a proposal but would need collaborators on the
>>> implementation side.
>> 
>> Typed throws is something we need to settle one way or the other,
>> and I agree it would be nice to do that in the Swift 5 cycle.
>> 
>> For the purposes of this sub-discussion, I think there are three kinds of code to think about: 
>> 1) large scale API like Cocoa which evolve (adding significant
>> functionality) over the course of many years and can’t break
>> clients.
>> 2) the public API of shared swiftpm packages, whose lifecycle may
>> rise and fall - being obsoleted and replaced by better packages if
>> they encounter a design problem.
>> 3) internal APIs and applications, which are easy to change because
>> the implementations and clients of the APIs are owned by the same
>> people.
>> 
>> These each have different sorts of concerns, and we hope that
>> something can start out as #3 but work its way up the stack
>> gracefully.
>> 
>> Here is where I think things stand on it:
>> - There is consensus that untyped throws is the right thing for a
>> large scale API like Cocoa.  NSError is effectively proven here.
>> Even if typed throws is introduced, Apple is unlikely to adopt it in
>> their APIs for this reason.
>> - There is consensus that untyped throws is the right default for people to reach for for public package (#2).
>> - There is consensus that Java and other systems that encourage
>> lists of throws error types lead to problematic APIs for a variety
>> of reasons.
>> - There is disagreement about whether internal APIs (#3) should use
>> it.  It seems perfect to be able to write exhaustive catches in this
>> situation, since everything in knowable. OTOH, this could encourage
>> abuse of error handling in cases where you really should return an
>> enum instead of using throws.
>> - Some people are concerned that introducing typed throws would
>> cause people to reach for it instead of using untyped throws for
>> public package APIs.
>
> Even for non-public code.  The only practical merit of typed throws I
> have ever seen someone demonstrate is that it would let them use
> contextual lookup in a throw or catch.  People always say "I'll be
> able to exhaustively switch over my errors", and then I ask them to
> show me where they want to do that, and they show me something that
> just logs the error, which of course does not require typed throws.
> Every.  Single.  Time.
>
> Sometimes we then go on to have a conversation about wrapping errors
> in other error types, and that can be interesting, but now we're
> talking about adding a big, messy feature just to get "safety"
> guarantees for a fairly minor need.
>
> Programmers often have an instinct to obsess over error taxonomies
> that is very rarely directed at solving any real problem; it is just
> self-imposed busy-work.

+1; I couldn't have said this any better.  

The problem is not merely that by implementing this we'd be expending
effort and adding language complexity; it's also that programmers love
to classify things and those working with statically-typed languages
have a natural inclination to think “more static type information is
better,” so they *will* use this feature whether it's good for code or
not.

-- 
-Dave