<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think the clear middle ground is an approach where you *can* document the type, but let it not be required.<div class=""><br class=""></div><div class="">Additionally, we can treat that at the calling end as a built time assurance of the type for error that is passed into the standard “catch { }”, and the compiler can also check that all of your catch let … casts actually are possible, and so catching becomes like a switch. I don’t see this as changing anything we currently do, except giving us the option to declare more than the current: Currently “throws” means “throws Error”. Why can’t we allow more information to be passed?</div><div class=""><br class=""></div><div class="">I think the compiler needs to remove the overhead of specified error types. Just like Java may be seen as a nightmare, it’s clear here that the fact we can specify different error types means *guessing* the error types is just as much of a nightmare. It makes sense, even if only for documentation reasons, to allow a declarable way of denoting your error type, and feeding that information to the compiler for built time checks.<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Dec 2016, at 10:20 pm, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">For me, handling Swift errors is a nightmare. You have no idea what to expect to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually errors meant for user interaction), but some use enums that even can have a payload (extra info about the error). And you need to rely on the documentation, which can be nonexistent or inaccurate. Not to mention, within that call, another throwing method can be called, which may not be mentioned in the docs, which may result in other error types being thrown.<div class=""><br class=""></div><div class="">And mainly, when the docs mention that only MyErrorEnum can be thrown, you have a catch branch for MyErrorEnum, but the compiler will complain that not all cases are handled. So you either need to catch a generic Error and force-cast it, or add another catch _ branch calling fatalError - unhandled error. Either way, not a pretty solution.</div><div class=""><br class=""></div><div class="">While I always hated Java's approach of listing all exceptions that can be thrown, I equally hate current state of Swift, where you have no idea what's comming at ya. In ObjC, you knew it was NSError. Yes, you still can bridge any Error to NSError, but you loose a lot of potentially useful information about the error.<br class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 27, 2016, at 10:57 AM, Daniel Leping via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">-1 for specifying errors for throws. Please don't. Proven by practice in java it's a nightmare.</div><div class=""><br class=""><div class="gmail_quote"><div class="">On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the idea of "throw" having information about what might be thrown.<br class="gmail_msg"><br class="gmail_msg">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?<br class="gmail_msg"><br class="gmail_msg">While adding the throwing info in the comments is good, we might be better off adding an attribute <br class="gmail_msg"><br class="gmail_msg">@throws(Error_Enum, Specific_error, ...)<br class="gmail_msg"><br class="gmail_msg">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...<br class="gmail_msg"><br class="gmail_msg">Then we can do something like this<br class="gmail_msg"><br class="gmail_msg">@throws(MyErrorEnum)<br class="gmail_msg">func foo() {<br class="gmail_msg">....<br class="gmail_msg">throw MyErrorEnum.firstError<br class="gmail_msg">....<br class="gmail_msg">}<br class="gmail_msg"><br class="gmail_msg">With this info we can properly catch all error cases<br class="gmail_msg"><br class="gmail_msg">do {<br class="gmail_msg"> try foo()<br class="gmail_msg">} catch MyErrorEnum.firstError {<br class="gmail_msg"><br class="gmail_msg">} catch {<br class="gmail_msg">}<br class="gmail_msg"><br class="gmail_msg">As for blocks that throw we could probably add it in the same place where @escaping is.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Maybe we can let the compiler use documentation comments for type-checking. Currently you can do:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">/// does something</div><div class="gmail_msg">///</div><div class="gmail_msg">/// - returns: Something cool</div><div class="gmail_msg">///</div><div class="gmail_msg">/// - throws:</div><div class="gmail_msg">/// - `MyError.Something` if a certain thing happens</div><div class="gmail_msg">/// - `POSIXError` if something goes horribly wrong</div><div class="gmail_msg">///</div><div class="gmail_msg">func doSomething() throws -> Int</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Just saying, there are options.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 27 Dec 2016, at 07:55, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="gmail_msg" target="_blank">tony.allevato@gmail.com</a>> wrote:</div><br class="m_-2005797514699306937m_8137774673651405685Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.<div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">I agree that this could do with revision. It looks particularly ugly when you’re dealing with throwing closures.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Recently I had a signature like:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><font style="font-size:11px" face="Menlo" class="gmail_msg">public func scan(length: File.ByteOffset.Stride?,<br class="gmail_msg"> by frameSize: File.ByteOffset.Stride,<br class="gmail_msg"> with handler: (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer) throws -> Bool) throws -> File.ByteOffset.Stride</font></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><font style="font-size:11px" face="Menlo" class="gmail_msg">public throwing func scan(length: File.ByteOffset.Stride?,<br class="gmail_msg"> by frameSize: File.ByteOffset.Stride,<br class="gmail_msg"> with handler: throwing (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer)->Bool) -> File.ByteOffset.Stride</font></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Karl</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_-2005797514699306937m_8137774673651405685m_6688193965959674782Apple-interchange-newline"></blockquote></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Hello Swifters,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For example,</div><div class="gmail_msg"><div class="gmail_msg m_-2005797514699306937m_8137774673651405685m_6688193965959674782bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;background-color:rgb(254,254,254)"><pre style="margin-top:15px;margin-bottom:15px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class="gmail_msg">// This is pretty clear, this can throw an error<br class=""><br class="">func foo() throws<br class=""><br class="">{ ... }<br class=""><br class=""><br class=""><br class="">// Also pretty clear, this returns a String<br class=""><br class="">func bar() -> String<br class=""><br class="">{ ... }<br class=""><br class=""><br class=""><br class="">// Confusing. Does this throw a String? Does it return a String? Does it do both?<br class=""><br class="">// I personally keep reading this as 'this can throw a String'<br class=""><br class="">func baz() throws -> String<br class=""><br class=""><br class=""><br class="">// Equivalent code in Java (not a model, just for clarification of why the above is confusing)<br class=""><br class="">String baz() throws StringFormatException</pre></div><div class="gmail_msg">I therefore suggest either tweaking the syntax around, or moving, the `throws` keyword to avoid this confusion.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Some ideas I've had:</div><div class="gmail_msg"><pre style="color:inherit;margin-top:15px;margin-bottom:15px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class="gmail_msg">// Add a comma to separate them<br class=""><br class="">func baz() throws, -> String<br class=""><br class=""><br class=""><br class="">// Move `throws` to the end<br class=""><br class="">func baz() -> String throws<br class=""><br class=""><br class=""><br class="">// Change it to a prefix modifier (like `mutating`)<br class=""><br class="">throwing func baz() -> String<br class=""><br class=""></pre></div><div class="gmail_msg">I'm still not sold on any of the above syntaxes, but I would love to hear your feedback.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 <i class="gmail_msg">especially</i> for those coming for a language such as Java.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="gmail_msg">-thislooksfun (tlf)</div><br class=""><br class=""><br class=""><br class=""></div><br class=""><br class=""><br class="gmail_msg"></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div></div>_______________________________________________<br class="gmail_msg"><br class=""><br class="">swift-evolution mailing list<br class="gmail_msg"><br class=""><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class=""><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class=""><br class=""></blockquote></div><br class=""><br class=""></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg"><br class=""><br class="">swift-evolution mailing list<br class="gmail_msg"><br class=""><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class=""><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class=""><br class=""></blockquote></div><br class=""><br class="">_______________________________________________<br class="gmail_msg"><br class="">swift-evolution mailing list<br class="gmail_msg"><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class=""></blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>