[swift-evolution] Move placement of 'throws' statement

Tue Dec 27 03:57:46 CST 2016

-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 at 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 at 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.allevato at 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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
>
>
> swift-evolution mailing list
>
>
> swift-evolution at swift.org
>
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
> _______________________________________________
>
>
> swift-evolution mailing list
>
>
> swift-evolution at swift.org
>
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
>
> swift-evolution mailing list
>
> swift-evolution at swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/47d368cf/attachment.html>