-1 for specifying errors for throws. Please don't. Proven by practice in java it's a nightmare.
On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > I like the idea of "throw" having information about what might be thrown. > > Maybe you have an enum of errors that may be thrown. How would the > programmer know what might get thrown if they don't know the implementation > details? > > While adding the throwing info in the comments is good, we might be better > off adding an attribute > > @throws(Error_Enum, Specific_error, ...) > > Where the stuff in parenthesis is a comma separated list of possible > errors. Maybe it's all the cases in enum are possible or maybe only a > specific few are used... > > Then we can do something like this > > @throws(MyErrorEnum) > func foo() { > .... > throw MyErrorEnum.firstError > .... > } > > With this info we can properly catch all error cases > > do { > try foo() > } catch MyErrorEnum.firstError { > > } catch { > } > > As for blocks that throw we could probably add it in the same place where > @escaping is. > On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > Maybe we can let the compiler use documentation comments for > type-checking. Currently you can do: > > /// does something > /// > /// - returns: Something cool > /// > /// - throws: > /// - `MyError.Something` if a certain thing happens > /// - `POSIXError` if something goes horribly wrong > /// > func doSomething() throws -> Int > > I would prefer if we found some way to integrate that stuff in to the > compiler. I mean, you would probably want to document why the errors get > thrown anyway, and it’s better than clobbering up the function signature. > > Maybe it seems weird to have the compiler look inside comments (especially > if the set of thrown errors becomes a resilience-breaking part of the > function), but why not? Swift’s documentation comments are just another > source of structured data, and the compiler already understands them at a > superficial level. > > Just saying, there are options. > > On 27 Dec 2016, at 07:55, Tony Allevato <tony.allev...@gmail.com> wrote: > > One thing to keep in mind is that, if I recall correctly, some members of > the core team have expressed a desire to enhance `throws` by letting users > list the specific error types that a function can throw. If that is > something that might happen in the future, moving the `throws/throwing` to > the front would add a significant amount of noise before the function name. > > > On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > I agree that this could do with revision. It looks particularly ugly when > you’re dealing with throwing closures. > > Recently I had a signature like: > > public func scan(length: File.ByteOffset.Stride?, > by frameSize: File.ByteOffset.Stride, > with handler: > (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer) throws -> > Bool) throws -> File.ByteOffset.Stride > > It can get difficult to parse the signature towards the end. Marking the > handler and function as throwing closer to the beginning would make it more > readable IMO. One thing it allows me to do more easily is to remove the > spaces around the arrow for the closure parameter (just a little thing > which I find helps me read the trailing closure/return type more quickly). > > public throwing func scan(length: File.ByteOffset.Stride?, > by > frameSize: File.ByteOffset.Stride, > with handler: throwing > (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer)->Bool) > -> File.ByteOffset.Stride > > - Karl > > On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello Swifters, > > I've been writing a lot more Swift code recently, and I have found that > the default placement of the 'throws' declaration is often confusing, > especially to those of us switching from languages where the type of errors > thrown is explicitly defined (like Java) > > For example, > > // This is pretty clear, this can throw an error > > func foo() throws > > { ... } > > > > // Also pretty clear, this returns a String > > func bar() -> String > > { ... } > > > > // Confusing. Does this throw a String? Does it return a String? Does it do > both? > > // I personally keep reading this as 'this can throw a String' > > func baz() throws -> String > > > > // Equivalent code in Java (not a model, just for clarification of why the > above is confusing) > > String baz() throws StringFormatException > > I therefore suggest either tweaking the syntax around, or moving, the > `throws` keyword to avoid this confusion. > > Some ideas I've had: > > // Add a comma to separate them > > func baz() throws, -> String > > > > // Move `throws` to the end > > func baz() -> String throws > > > > // Change it to a prefix modifier (like `mutating`) > > throwing func baz() -> String > > I'm still not sold on any of the above syntaxes, but I would love to hear > your feedback. > > This would affect existing code, but it would be a fairly small change > that would result in very large readability improvements, especially for > newcomers, and *especially* for those coming for a language such as Java. > > -thislooksfun (tlf) > > > > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution