<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Imho the concept of checked exceptions was ok, but the important information is the category of error - in how to respond and how to report to the user. Use of a type system encourages an ontology of errors by subsystem and not by appropriate programmatic response. You could have appropriate user interaction or recovery in response to "specified file was not found", but not to "some IO error has occurred". </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Eventually this impedance mismatch grew to having modules (packages) in Java "wrap" all errors in a module-specific error. Now it wasn't even "some IO error occurred" but "some error occurred in the XML module"</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">This is the danger of checked exceptions - that abstracting away the error makes it harder to reason about dealing with the error, so you just delegate further up the call stack, abstracting further as you go</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">-DW</div><div id="AppleMailSignature"><br><br>Sent with my Thumbs</div><div><br>On Dec 27, 2016, at 6:21 AM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">You need to list all exception types that can be thrown. And when you call another throwing method without handling the exception, it needs to be listed as well. Which means that you can end up with a method that has a list of a dozen of exception names that can be thrown.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 27, 2016, at 11:56 AM, Derrick Ho 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="">Daniel Leping, I am unfamiliar with java. Do you have any resources that describe the nightmare in detail?<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" 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"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="gmail_msg">-1 for specifying errors for throws. Please don't. Proven by practice in java it's a nightmare.</span></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">In Java, this topic is really interesting:</div><div class="gmail_msg">It sounds like a great idea, but in real-life situations, afaics everyone hates checked exceptions.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But Swift isn't Java, and our error handling is different from most established languages, so imho we shouldn't base that decision on experiences from other models only:</div><div class="gmail_msg">I don't see downsides, because you already need "try" for everything that can throw, and afaics, it would be easy to ignore the information that only a set of exceptions can happen in a given context.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So, imho before there is a decision wether "throws" should be moved, the possibility to annotate it with a fixed set of error types should be either abandoned or incorporated. </div></div></blockquote></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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>