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 <[email protected]> a écrit : > > >> On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution >> <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
