[swift-evolution] typed throws

[John McCall]

> On Aug 18, 2017, at 3:24 AM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> 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.
> 
> I think the aspect of documentation shouldn't be underestimated:
> People want to know what might go wrong — even if they have only a single reaction to all cases at their disposal.

There's no reason we couldn't do some tooling work to expose emergent information about what kinds of errors are thrown by the current implementation of a function, and maybe even check that against the current documentation.  Certainly, it should be possible to document particularly interesting errors that a function might throw.  I'm just challenging the idea that this should be reflected and enforced in the type system.

> Typed throws could also help to lessen the tight coupling to Objective-C:
> Being forced to declare conformance to a protocol without requirements or even public methods feels very awkward to me.

Error is not about Objective-C interop; we could make the feature work without a protocol, and in fact the protocol alone isn't sufficient for what we try to do with it.  The protocol's value is mostly communicative, a way of making it obvious that a type is meant to be thrown, as well as to verify that you aren't accidentally throwing something nonsensical.

It also gives us a hook to add defaulted requirements in a later release.

> In some way, throws are typed already, but there's just one type allowed, and it can't be changed.
> 
> Imho the big problem of the whole topic is the bad experience people had with typed throws in Java; I don't see a problem in adding typed throws and keeping Error as default type to be thrown if nothing else is specified.

The problems people have with typed throws in Java aren't ultimately because of some specific failure of Java (although there are certainly ways in which Java's design could be better in my opinion).  They pretty much all arise directly from conceptual problems with the idea of "restricted" sets of errors.

> If people want to build huge lists of possible errors… why not? As long as I'm still able to write my own throwing functions as today, I'm fine with that.

Language features have to meet a higher bar than "why not?".

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/016ae79a/attachment.html>