Hi John, tl;dr I think throws should be optionally typed. Ie. `func someSyscall(...) throws(POSIXError) -> Int` should be just as legal as `func doSomeFancyCocoaOperation() throws -> Void`.
> [...] >> 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. I just grep'ed through some code and what I always see is this: } catch let e { fatalError("unexcepted error caught: \(e)") } most of the code is fairly low-level and the only error thrown in there is a POSIXError which basically holds the errno value and a string describing the failed syscall. I find this a very common pattern. Also the IMHO quite widespread use of Result<E, T> types shows that there are valid uses of a typed error mechanism. On the other hand requiring a high-level Cocoa method to declare all errors doesn't seem right either. So why not optionally typing the throws? > [...] -- Johannes _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution