[swift-evolution] Type-annotated throws

Félix Cloutier felixcca at yahoo.ca
Tue Aug 30 01:05:13 CDT 2016


I see two main use cases for throws right now:

for high-level operations that can fail for a lot of reasons
when it's convenient to bubble out of a complex, nested/recursive algorithm (like parsing a data structure)

Throws works well for case one, but it's not awesome for case two. I don't think that adding an optional type annotation to throws would hurt case one a lot, too.

Félix

> Le 29 août 2016 à 21:13:51, Russ Bishop <xenadu at gmail.com> a écrit :
> 
> 
>> On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hi all,
>> 
>> Currently, a function that throws is assumed to throw anything. There was a proposal draft last December to restrict that. The general idea was that you'd write, for instance:
>> 
>>> enum Foo: ErrorProtocol {
>>>    case bar
>>>    case baz
>>> }
>>> 
>>> func frob() throws Foo {
>>>    throw Foo.bar // throw .bar?
>>> }
>> 
>> If you `catch Foo` (or every case of Foo), now that the compiler can verify that your catch is exhaustive, you no longer have to have a catch-all block at the end of the sequence.
> 
> This contract is a lie in almost all real-world programs because real programs talk to the network, the filesystem, the database, etc and the class of errors that can be thrown is tremendous. The number of functions where “throws Foo” is an improvement and Foo is not an exhaustive list of “throws HTTPError, NetworkError, StorageError, DatabaseError, MachPortError, …” is close enough to zero to be considered zero. This ultimately leads to library authors merely wrapping exceptions using generic catch-all blocks anyway, adding no useful information.
> 
> There is zero value to adding it without the compiler enforcing it because you can only omit default catch blocks safely when you can be certain the list of exceptions is exhaustive.
> 
> I am sympathetic to the default/generic catch block problem but we could certainly solve that with some added syntax or automatic insertion of a rethrow if an error doesn’t match, meaning any function with a try{} and no default catch must itself be a throwing function.
> 
> 
> 
> Since this isn’t applicable to Swift 4 phase 1 I’ll hush now :)
> 
> Russ
> 

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


More information about the swift-evolution mailing list